From nobody Thu Nov 16 19:03:35 2023 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 4SWTvq1HyPz510HG for ; Thu, 16 Nov 2023 19:03:35 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SWTvq13bsz3Wss for ; Thu, 16 Nov 2023 19:03:35 +0000 (UTC) (envelope-from daemon-user@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700161415; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=fl9LoJggxfzDikPeAaH9y6CTHBiJk4zUnephdm2UhxM=; b=peCLIuRncJGDBmQglKaJHBuKahJa2Fe8SrQE1IBVCUCA4JSbrzkGlNozRFdq+sfbT1hnyE LVa0JONyTbrnFkwtCO86KoLnPWq6XOC+HLznorOCviZGVDqwmuzjKNlgcr8VKTYDVEEQiU 0Sooo9ug5yEZoMhVaxf/WYqh7jWwBu+Ng2F390X0j21U0EaTvJ83991CStdAeL7PzWv4aW xjpIG1GibfqgidN9nJBr5pT7FRbUW80sT4iiH8T/K6uWjPpRiJnT3Jf7z4HFXyluQZoL0d Zu1++/vCAWze1BLc5OGO51yqGyL7FvPQNeCCX7QuumVljXrpHKF2ExXvkJlyWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700161415; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=fl9LoJggxfzDikPeAaH9y6CTHBiJk4zUnephdm2UhxM=; b=AaeqtV4oK2AvRa4pVTc4QtJaPVy/kNd/WdEYXZVH+HjyLHKEUm3ljBNCI6xC+wGRN7uHs5 7eScEw9u8ceMppyC8hiT6QymxRGJHuwejZ5unrINp+kOIdWshwJf+XrILOHLsdJrVdNUts fK4bvQ7Du3hqQYkWU7qn02NVHGGFJS/8YHFoCTgWJ6jrocDqKmvTFU9JcJJYQTpBWqIqVl qeb3ABoA/nCPsmSQIx8brbgpuy7oU38hdI44tJkrbWuoaPpNqxsVxORAkgNBPMGfOp7Wht E39qxtTDhebiKSJkUyo+dW9QQ5juQL92bbTha7kmeDwpcdRi0gtubpOCs78L9w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1700161415; a=rsa-sha256; cv=none; b=QWBIMdorK2TzDTj1peRDfLlQfnqJ+ueZ6PLkqhTdWSYGDbEbGC42wi53q9D2/W6tE78IXQ sunUhBq0wtuA/MdOC8XFvh7UAcvjom07bu0KkmVZIro7lWUgI6XF1+kXHibnb7V5iWjGcf C6IysuEyy/YeTJm2IcIeb82wALX2d8k1OjNiSg4lWBHoZ2DPuuKnfsg8xPYGtXQ+yzzcV3 LEn4KEbfydla7FNZWeNLy9BMPvKfR7VPMcqtLly1mVK1uEQehFSPB9a3oji6Qzclh4SmxK gy3EnFkDAEUafxn7BHY3tSGPeKFBxPK3e4hhMZqGWe+c69qCsDVy/x+HD7JbnA== Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:606c::16:b]) by mxrelay.nyi.freebsd.org (Postfix) with ESMTP id 4SWTvq08jBz1BWN for ; Thu, 16 Nov 2023 19:03:35 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 03C9A44A83; Thu, 16 Nov 2023 19:03:35 +0000 (UTC) Date: Thu, 16 Nov 2023 19:03:35 +0000 To: freebsd-arm@freebsd.org From: "titus_edc.ro (Titus Manea)" Reply-to: "titus_edc.ro (Titus Manea)" Subject: [Differential] D42638: Rockchip RNG Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , X-Herald-Rules: <28>, <31>, <32>, <34>, <177>, <79> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk Thread-Topic: PHID-DREV-d2ijur6r7trb5hmp22or X-Phabricator-Mail-ID: 4156725 X-Phabricator-Send-Attempt: p3afaifxhayaf44c In-Reply-To: References: Thread-Index: OWFmNTUxOTI4ODQ5ZTcyYzhiMjc4N2YxM2RmIGVWZ4c= X-Phabricator-Stamps: actor(@titus_edc.ro) application(Differential) author(@titus_edc.ro) herald(H28) herald(H31) herald(H32) herald(H34) herald(H79) herald(H177) monogram(D42638) object-type(DREV) phid(PHID-DREV-d2ijur6r7trb5hmp22or) reviewer(@andrew) reviewer(@freebsd-arm-list) revision-repository(rG) revision-status(needs-review) subscriber(@emaste) subscriber(@imp) via(web) 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: multipart/mixed; boundary="b1_d0957a9db152ebc6cc15e86a0f83e5c2" --b1_d0957a9db152ebc6cc15e86a0f83e5c2 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: base64 dGl0dXNfZWRjLnJvIGNyZWF0ZWQgdGhpcyByZXZpc2lvbi4KdGl0dXNfZWRjLnJvIGFkZGVkIGEg cmV2aWV3ZXI6IGZyZWVic2QtYXJtLWxpc3QuCkhlcmFsZCBhZGRlZCBzdWJzY3JpYmVyczogZW1h c3RlLCBpbXAuCkhlcmFsZCBhZGRlZCBhIHJldmlld2VyOiBhbmRyZXcuCkhlcmFsZCBhZGRlZCBh IHJldmlld2VyOiBhbmRyZXcuCkhlcmFsZCBhZGRlZCBhIHJldmlld2VyOiBhbmRyZXcuCnRpdHVz X2VkYy5ybyByZXF1ZXN0ZWQgcmV2aWV3IG9mIHRoaXMgcmV2aXNpb24uCgpSRVZJU0lPTiBTVU1N QVJZCiAgcm9ja2NoaXAgcm5nIHN1cHBvcnQsIHNpbWlsYXIgd2l0aCBiY20yODM1X3JuZwogIHJh bmRvbSBkYXRhIGdlbmVyYXRlZCBpcyBwYXNzZWQgdG8KICByYW5kb21faGFydmVzdF9xdWV1ZQog IAogIHYxIGFuZCB2MiBzdXBwb3J0ZWQgb25seSB2MiB0ZXN0ZWQKICByYW5kb21uZXNzIG9mIGRh dGEgZ2VuZXJhdGVkIG9ubHkgdGVzdGVkIHdpdGggdGhlICdleWUgdGVzdCcKClJFUE9TSVRPUlkK ICByRyBGcmVlQlNEIHNyYyByZXBvc2l0b3J5CgpSRVZJU0lPTiBERVRBSUwKICBodHRwczovL3Jl dmlld3MuZnJlZWJzZC5vcmcvRDQyNjM4CgpBRkZFQ1RFRCBGSUxFUwogIGFybTY0L3JvY2tjaGlw L3JrX3JuZy5jCgpFTUFJTCBQUkVGRVJFTkNFUwogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9y Zy9zZXR0aW5ncy9wYW5lbC9lbWFpbHByZWZlcmVuY2VzLwoKVG86IHRpdHVzX2VkYy5ybywgZnJl ZWJzZC1hcm0tbGlzdCwgYW5kcmV3CkNjOiBpbXAsIGVtYXN0ZSwgcHN0ZWYK --b1_d0957a9db152ebc6cc15e86a0f83e5c2 Content-Type: text/x-patch; charset=utf-8; name="D42638.130216.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D42638.130216.patch" ZGlmZiAtLWdpdCBhL2FybTY0L3JvY2tjaGlwL3JrX3JuZy5jIGIvYXJtNjQvcm9ja2NoaXAvcmtf cm5nLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKLS0tIC9kZXYvbnVsbAorKysgYi9hcm02NC9yb2Nr Y2hpcC9ya19ybmcuYwpAQCAtMCwwICsxLDM3NyBAQAorLyoKKyAqIENvcHlyaWdodCAoYykgMjAy MyB0aXR1c20gdGl0dXNAZWRjLnJvCisgKgorICogYmFzZWQgb24gJE9wZW5CU0Q6IHJrcm5nLmMs diAxLjUgMjAyMy8wNC8xNCAwMToxMTozMiBkbGcgRXhwICQKKyAqIENvcHlyaWdodCAoYykgMjAy MCBNYXJrIEtldHRlbmlzIDxrZXR0ZW5pc0BvcGVuYnNkLm9yZz4KKyAqCisgKiBSZWRpc3RyaWJ1 dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQK KyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dp bmcgY29uZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3Vy Y2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRo aXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAy LiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3Zl IGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhl IGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Ig b3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBU SElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBg YEFTIElTJycgQU5ECisgKiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xV RElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBN RVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBB UkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVU T1JTIEJFIExJQUJMRQorICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBT UEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElO RywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisg KiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNT IElOVEVSUlVQVElPTikKKyAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJ QUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRP UlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZ CisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0Yg VEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqLworCisKKyNpbmNsdWRlIDxz eXMvcGFyYW0uaD4KKyNpbmNsdWRlIDxzeXMva2VybmVsLmg+CisjaW5jbHVkZSA8c3lzL2t0ci5o PgorI2luY2x1ZGUgPHN5cy9sb2NrLmg+CisjaW5jbHVkZSA8c3lzL21hbGxvYy5oPgorI2luY2x1 ZGUgPHN5cy9tb2R1bGUuaD4KKyNpbmNsdWRlIDxzeXMvcmFuZG9tLmg+CisjaW5jbHVkZSA8c3lz L3NlbGluZm8uaD4KKyNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KKyNpbmNsdWRlIDxzeXMvYnVzLmg+ CisjaW5jbHVkZSA8ZGV2L2V4dHJlcy9jbGsvY2xrLmg+CisjaW5jbHVkZSA8ZGV2L2V4dHJlcy9o d3Jlc2V0L2h3cmVzZXQuaD4KKyNpbmNsdWRlIDxzeXMvcm1hbi5oPgorCisjaW5jbHVkZSA8bWFj aGluZS9idXMuaD4KKyNpbmNsdWRlIDxtYWNoaW5lL3Jlc291cmNlLmg+CisKKyNpbmNsdWRlIDxk ZXYvb2Z3L29wZW5maXJtLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzLmg+CisjaW5jbHVk ZSA8ZGV2L29mdy9vZndfYnVzX3N1YnIuaD4KKworI2luY2x1ZGUgPGRldi9yYW5kb20vcmFuZG9t ZGV2Lmg+CisjaW5jbHVkZSA8ZGV2L3JhbmRvbS9yYW5kb21faGFydmVzdHEuaD4KKworc3RhdGlj IGRldmljZV9hdHRhY2hfdCBya19ybmdfYXR0YWNoOworc3RhdGljIGRldmljZV9kZXRhY2hfdCBy a19ybmdfZGV0YWNoOworc3RhdGljIGRldmljZV9wcm9iZV90IHJrX3JuZ19wcm9iZTsKKworLyog VjEgKi8KKyNkZWZpbmUgUk5HX1YxX0NUUkwJCQkJMHgwMDA4CisjZGVmaW5lICBSTkdfVjFfQ1RS TF9TVEFSVAkJCSgxIDw8IDgpCisjZGVmaW5lIFJOR19WMV9DVFJMMgkJCQkweDAyMDAKKyNkZWZp bmUgIFJOR19WMV9DVFJMMl9PU0NfRU5BQkxFCQkoMSA8PCAxNikKKyNkZWZpbmUgUk5HX1YxX0RB VEEwCQkJCTB4MDIwNAorCisvKiBUcnVlIFJhbmRvbSBOdW1iZXIgR2VuZXJhdG9yIChUUk5HKSAq LworI2RlZmluZSBSTkdfVjJfUlNUX0NUTAkJCQkweDAwMDQKKyNkZWZpbmUgIFJOR19WMl9SU1Rf Q1RMX1NXX1JOR19SRVNFVAkJKDB4MVUgPDwgMSkKKyNkZWZpbmUgUk5HX1YyX0NUTAkJCQkweDA0 MDAKKyNkZWZpbmUgIFJOR19WMl9DVExfUk5HX1NUQVJUCQkJKDB4MVUgPDwgMCkKKyNkZWZpbmUg IFJOR19WMl9DVExfUk5HX0VOQUJMRQkJCSgweDFVIDw8IDEpCisjZGVmaW5lICBSTkdfVjJfQ1RM X1JJTkdfU0VMX01BU0sJCSgweDNVIDw8IDIpCisjZGVmaW5lICBSTkdfVjJfQ1RMX1JJTkdfU0VM X1NMT1dFU1QJCSgweDBVIDw8IDIpCisjZGVmaW5lICBSTkdfVjJfQ1RMX1JJTkdfU0VMX1NMT1cJ CSgweDFVIDw8IDIpCisjZGVmaW5lICBSTkdfVjJfQ1RMX1JJTkdfU0VMX0ZBU1QJCSgweDJVIDw8 IDIpCisjZGVmaW5lICBSTkdfVjJfQ1RMX1JJTkdfU0VMX0ZBU1RFU1QJCSgweDNVIDw8IDIpCisj ZGVmaW5lICBSTkdfVjJfQ1RMX1JOR19MRU5fTUFTSwkJKDB4M1UgPDwgNCkKKyNkZWZpbmUgIFJO R19WMl9DVExfUk5HX0xFTl82NAkJCSgweDBVIDw8IDQpCisjZGVmaW5lICBSTkdfVjJfQ1RMX1JO R19MRU5fMTI4CQkJKDB4MVUgPDwgNCkKKyNkZWZpbmUgIFJOR19WMl9DVExfUk5HX0xFTl8xOTIJ CQkoMHgyVSA8PCA0KQorI2RlZmluZSAgUk5HX1YyX0NUTF9STkdfTEVOXzI1NgkJCSgweDNVIDw8 IDQpCisjZGVmaW5lIFJOR19WMl9TQU1QTEVfQ05UCQkJMHgwNDA0CisjZGVmaW5lIFJOR19WMl9E QVRBMAkJCQkweDA0MTAKKworI2RlZmluZQlSTkdfRFdPUkRTCQk4CisjZGVmaW5lCVJOR19DQUxM T1VUX1RJQ0tTCShoeiAqIDQpCisjZGVmaW5lIFJOR19USU1FT1VUX1RJQ0tTCTEwMAorCisjZGVm aW5lCVdSNChfc2MsIF9yLCBfdikJYnVzX3dyaXRlXzQoKF9zYyktPnNjX3Jlc1swXSwgKF9yKSwg KF92KSkKKyNkZWZpbmUJUkQ0KF9zYywgX3IpCQlidXNfcmVhZF80KChfc2MpLT5zY19yZXNbMF0s IChfcikpCisKKyNpZiAwCisgI2RlZmluZSBkcHJpbnRmKGRldiwgZm9ybWF0LCBhcmcuLi4pICAg ICBkZXZpY2VfcHJpbnRmKGRldiwgIiVzOiAiIGZvcm1hdCwgX19mdW5jX18sIGFyZykKKyNlbHNl CisgI2RlZmluZSBkcHJpbnRmKGRldiwgZm9ybWF0LCBhcmcuLi4pCisjZW5kaWYKKworc3RhdGlj IHN0cnVjdCByZXNvdXJjZV9zcGVjIHJrX3JuZ19zcGVjW10gPSB7CisgICAgICAgIHsgU1lTX1JF U19NRU1PUlksICAgICAgIDAsICAgICAgUkZfQUNUSVZFIH0sCisgICAgICAgIHsgLTEsIDAgfQor fTsKKworCitzdHJ1Y3Qgcmtfcm5nX3NvZnRjIHsKKwlkZXZpY2VfdAkJc2NfZGV2OworCXN0cnVj dCByZXNvdXJjZSAJKnNjX3Jlc1sxXTsKKwlzdHJ1Y3Qgcmtfcm5nX2NvbmYgCSogc2NfY29uZjsK KwlzdHJ1Y3QgY2FsbG91dAkJc2Nfcm5ndG87CisJdWludDhfdCAJCXNjX3BzdGF0OworCXVpbnQ4 X3QgCQlzY193ZG9nOworfTsKKworc3RydWN0IHJrX3JuZ19jb25mIHsKKwl1bnNpZ25lZCBpbnQJ dmVyOworCWNvbnN0IGNoYXIJKm5hbWU7CisJdWludDMyX3QJKCpvbikoc3RydWN0IHJrX3JuZ19z b2Z0YyAqc2MpOworCXZvaWQgCQkoKm9mZikoc3RydWN0IHJrX3JuZ19zb2Z0YyAqc2MpOworCWJ1 c19zaXplX3QJZGF0YV9vdXQ7Cit9OworCitlbnVtIFJLX1JOR19QU1RBVCB7CisJUktfUk5HX1NU T1BQRUQgPSAwLAorCVJLX1JOR19TVEFSVElORywKKwlSS19STkdfU1RBUlRFRAorCX07CisKK3N0 YXRpYyB1aW50MzJfdAkJcmtfcm5nX3YxX29uKHN0cnVjdCBya19ybmdfc29mdGMgKik7CitzdGF0 aWMgdm9pZAkJcmtfcm5nX3YxX29mZihzdHJ1Y3Qgcmtfcm5nX3NvZnRjICopOworCitzdGF0aWMg Y29uc3Qgc3RydWN0IHJrX3JuZ19jb25mIHJrdjFfY29uZiA9IHsKKwkudmVyCQk9IDEsCisJLm5h bWUJCT0gIlJvY2tjaGlwIFJORyB2MSIsCisJLm9uCQk9IHJrX3JuZ192MV9vbiwKKwkub2ZmCQk9 IHJrX3JuZ192MV9vZmYsCisJLmRhdGFfb3V0CT0gUk5HX1YxX0RBVEEwLAorfTsKKworc3RhdGlj IHVpbnQzMl90CQlya19ybmdfdjJfb24oc3RydWN0IHJrX3JuZ19zb2Z0YyAqKTsKK3N0YXRpYyB2 b2lkCQlya19ybmdfdjJfb2ZmKHN0cnVjdCBya19ybmdfc29mdGMgKik7CisKK3N0YXRpYyBjb25z dCBzdHJ1Y3Qgcmtfcm5nX2NvbmYgcmt2Ml9jb25mID0geworCS52ZXIJCT0gMiwKKwkubmFtZQkJ PSAiUm9ja2NoaXAgUk5HIHYyIiwKKwkub24JCT0gcmtfcm5nX3YyX29uLAorCS5vZmYJCT0gcmtf cm5nX3YyX29mZiwKKwkuZGF0YV9vdXQJPSBSTkdfVjJfREFUQTAsCit9OworCitzdGF0aWMgc3Ry dWN0IG9md19jb21wYXRfZGF0YSBjb21wYXRfZGF0YVtdID0geworCXsicm9ja2NoaXAsY3J5cHRv djEtcm5nIiwJCSh1aW50cHRyX3QpJnJrdjFfY29uZn0sCisJeyJyb2NrY2hpcCxjcnlwdG92Mi1y bmciLAkJKHVpbnRwdHJfdCkmcmt2Ml9jb25mfSwKKwl7TlVMTCwJCQkJMH0KK307CisKK3N0YXRp YyB1aW50MzJfdAorcmtfcm5nX3YxX29uKHN0cnVjdCBya19ybmdfc29mdGMgKnNjKQoreworCWlm KHNjLT5zY19wc3RhdCA9PSBSS19STkdfU1RPUFBFRCkgeworCQlXUjQoc2MsIFJOR19WMV9DVFJM MiwgUk5HX1YxX0NUUkwyX09TQ19FTkFCTEUgfDEwMCk7CisJCVdSNChzYywgUk5HX1YxX0NUUkws IChSTkdfVjFfQ1RSTF9TVEFSVCA8PCAxNikgfCBSTkdfVjFfQ1RSTF9TVEFSVCk7CisJCXNjLT5z Y19wc3RhdCA9IFJLX1JOR19TVEFSVElORzsKKwkJfSBlbHNlIHsKKwkJc2MtPnNjX3BzdGF0ID0g KFJENChzYywgUk5HX1YxX0NUUkwpICYgUk5HX1YxX0NUUkxfU1RBUlQpID8KKwkJCVJLX1JOR19T VEFSVElORyA6IFJLX1JOR19TVEFSVEVEOworCX0KKwlyZXR1cm4gKHNjLT5zY19wc3RhdCk7Cit9 CisKKworCitzdGF0aWMgdm9pZAorcmtfcm5nX3YxX29mZihzdHJ1Y3Qgcmtfcm5nX3NvZnRjICpz YykKK3sKKwlXUjQoc2MsIFJOR19WMV9DVFJMLCAoUk5HX1YxX0NUUkxfU1RBUlQgPDwgMTYpIHwg MCk7CisJc2MtPnNjX3BzdGF0ID0gUktfUk5HX1NUT1BQRUQ7Cit9CisKK3N0YXRpYyB1aW50MzJf dAorcmtfcm5nX3YyX29uKHN0cnVjdCBya19ybmdfc29mdGMgKnNjKQoreworCSB1aW50MzJfdCBt YXNrLCB2YWw7CisKKwkgaWYoc2MtPnNjX3BzdGF0ID09IFJLX1JOR19TVE9QUEVEKSB7CisJCW1h c2sgPSBSTkdfVjJfQ1RMX1JOR19TVEFSVCB8IFJOR19WMl9DVExfUk5HX0VOQUJMRSB8CisJCSAg ICBSTkdfVjJfQ1RMX1JJTkdfU0VMX01BU0sgfCBSTkdfVjJfQ1RMX1JOR19MRU5fTUFTSzsKKwkJ dmFsID0gUk5HX1YyX0NUTF9STkdfU1RBUlQgfCBSTkdfVjJfQ1RMX1JOR19FTkFCTEUgfAorCQkg ICAgUk5HX1YyX0NUTF9SSU5HX1NFTF9TTE9XIHwgUk5HX1YyX0NUTF9STkdfTEVOXzI1NjsKKwkJ ICAgIFdSNChzYywgUk5HX1YyX1NBTVBMRV9DTlQsIDEwMCk7CisJCSAgICBXUjQoc2MsIFJOR19W Ml9DVEwsIChtYXNrIDw8IDE2KSB8IHZhbCk7CisJCSAgICBzYy0+c2NfcHN0YXQgPSBSS19STkdf U1RBUlRJTkc7CisJIH0gZWxzZSB7CisgICAgICAgICAgICAgICAgc2MtPnNjX3BzdGF0ID0gKFJE NChzYywgUk5HX1YyX0NUTCkgJiBSTkdfVjJfQ1RMX1JOR19TVEFSVCkgPworICAgICAgICAgICAg ICAgICAgICAgICAgUktfUk5HX1NUQVJUSU5HIDogUktfUk5HX1NUQVJURUQ7CisKKwkgfQorCSBy ZXR1cm4gKHNjLT5zY19wc3RhdCk7Cit9CisKKworc3RhdGljIHZvaWQKK3JrX3JuZ192Ml9vZmYo c3RydWN0IHJrX3JuZ19zb2Z0YyAqc2MpCit7CisJdWludDMyX3QgdmFsID0gUk5HX1YyX0NUTF9S TkdfU1RBUlQgfCBSTkdfVjJfQ1RMX1JOR19FTkFCTEU7CisKKwlXUjQoc2MsIFJOR19WMl9DVEws ICh2YWwgPDwgMTYpIHwgMCk7CisJc2MtPnNjX3BzdGF0ID0gUktfUk5HX1NUT1BQRUQ7Cit9CisK KworCitzdGF0aWMgdm9pZAorcmtfcm5nX2hhcnZlc3Qodm9pZCAqYXJnKQoreworCXN0cnVjdCBy a19ybmdfc29mdGMgKnNjID0gYXJnOworCXVpbnQzMl90IHJlZywgYnVmW1JOR19EV09SRFNdOwor CisJaWYoc2MtPnNjX3dkb2cgPiBSTkdfVElNRU9VVF9USUNLUykgeworCQlzYy0+c2Nfd2RvZyA9 IDA7CisJCWRwcmludGYoc2MtPnNjX2RldiwgIndhdGNoZG9nIHRpbWVvdXQgYWZ0ZXIgJWQgdHJp ZXNcbiIsIFJOR19USU1FT1VUX1RJQ0tTKTsKKwkJZ290byBvdXQ7CisJfQorCisJaWYoc2MtPnNj X2NvbmYtPm9uKHNjKSAhPSBSS19STkdfU1RBUlRFRCkgeworCQlzYy0+c2Nfd2RvZysrOworCQlj YWxsb3V0X3Jlc2V0X3NidCgmc2MtPnNjX3JuZ3RvLCBTQlRfMVVTICogMTAwLCAwLCBya19ybmdf aGFydmVzdCwgc2MsIDApOworCQlyZXR1cm47CisJfQorCisJZm9yKHJlZyA9IDA7IHJlZyA8IFJO R19EV09SRFM7cmVnKyspIHsKKwkJYnVmW3JlZ10gPSBSRDQoc2MsIChzYy0+c2NfY29uZi0+ZGF0 YV9vdXQgKyAocmVnIDw8IDIpKSk7CisJCWRwcmludGYoc2MtPnNjX2RldiwgInJlZ1slZF0gPT4g JTA4eFxuIiwgcmVnLCBidWZbcmVnXSk7CisJfQorCXJhbmRvbV9oYXJ2ZXN0X3F1ZXVlKGJ1Ziwg c2l6ZW9mKGJ1ZiksIFJBTkRPTV9QVVJFX0JST0FEQ09NKTsKKworb3V0OgorCXNjLT5zY193ZG9n ID0gMDsKKwlzYy0+c2NfY29uZi0+b2ZmKHNjKTsKKwljYWxsb3V0X3Jlc2V0KCZzYy0+c2Nfcm5n dG8sIFJOR19DQUxMT1VUX1RJQ0tTLCBya19ybmdfaGFydmVzdCwgc2MpOworfQorCisKK3N0YXRp YyBpbnQKK3JrX3JuZ19wcm9iZShkZXZpY2VfdCBkZXYpCit7CisJc3RydWN0IHJrX3JuZ19jb25m ICpjb21wYXQ7CisJaWYgKCFvZndfYnVzX3N0YXR1c19va2F5KGRldikpCisJCXJldHVybiAoRU5Y SU8pOworCisJY29tcGF0ID0gKHN0cnVjdCBya19ybmdfY29uZiAqKSBvZndfYnVzX3NlYXJjaF9j b21wYXRpYmxlKGRldiwgY29tcGF0X2RhdGEpLT5vY2RfZGF0YTsKKwlpZiAoIWNvbXBhdCkKKwkJ cmV0dXJuIChFTlhJTyk7CisKKwlkZXZpY2Vfc2V0X2Rlc2MoZGV2LCBjb21wYXQtPm5hbWUpOwor CisJcmV0dXJuIChCVVNfUFJPQkVfREVGQVVMVCk7Cit9CisKK3N0YXRpYyBpbnQKK3JrX3JuZ19h dHRhY2goZGV2aWNlX3QgZGV2KQoreworCXN0cnVjdCBya19ybmdfc29mdGMgKnNjOworCWludCBl cnJvciA9IDAsIGksIG5jZWxsczsKKwljbGtfdCBjbGs7CisJaHdyZXNldF90IGh3cmVzZXQgPSBO VUxMOworCXBoYW5kbGVfdCBub2RlOworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJ c2MtPnNjX2RldiA9IGRldjsKKworCXNjLT5zY19jb25mID0gKHN0cnVjdCBya19ybmdfY29uZiAq KW9md19idXNfc2VhcmNoX2NvbXBhdGlibGUoZGV2LCBjb21wYXRfZGF0YSktPm9jZF9kYXRhOwor CWlmKCFzYy0+c2NfY29uZikgeworCQllcnJvciA9IEVOWElPOworCQlnb3RvIGZhaWw7CisJfQor CisgICAgICAgIGlmIChidXNfYWxsb2NfcmVzb3VyY2VzKGRldiwgcmtfcm5nX3NwZWMsIHNjLT5z Y19yZXMpICE9IDApIHsKKyAgICAgICAgICAgICAgICBkZXZpY2VfcHJpbnRmKGRldiwgImNhbm5v dCBhbGxvY2F0ZSByZXNvdXJjZXMgZm9yIGRldmljZVxuIik7CisgICAgICAgICAgICAgICAgZXJy b3IgPSBFTlhJTzsKKyAgICAgICAgICAgICAgICBnb3RvIGZhaWw7CisgICAgICAgIH0KKworICAg ICAgICBub2RlID0gb2Z3X2J1c19nZXRfbm9kZShkZXYpOworCisJaWYgKE9GX2hhc3Byb3Aobm9k ZSwgImFzc2lnbmVkLWNsb2NrcyIpKSB7CisJCWVycm9yID0gY2xrX3NldF9hc3NpZ25lZChkZXYs IG5vZGUpOworCQlpZihlcnJvcikgeworCQkJZGV2aWNlX3ByaW50ZihkZXYsICJDb3VsZCBub3Qg c2V0IGFzc2lnbmVkIGNsb2Nrc1xuIik7CisJCQlnb3RvIGZhaWw7CisJCX0KKwl9CisKKyAgICAg ICAgZXJyb3IgPSBvZndfYnVzX3BhcnNlX3hyZWZfbGlzdF9nZXRfbGVuZ3RoKG5vZGUsICJjbG9j a3MiLAorICAgICAgICAgICAgIiNjbG9jay1jZWxscyIsICZuY2VsbHMpOworICAgICAgICBpZiAo ZXJyb3IgIT0gMCB8fCBuY2VsbHMgPCAyKSB7CisgICAgICAgICAgICAgICAgZGV2aWNlX3ByaW50 ZihkZXYsICJjb3VsZG4ndCBmaW5kIGVub3VnaCBjbG9ja3NcbiIpOworICAgICAgICAgICAgICAg IGVycm9yID0gRU5YSU87CisgICAgICAgICAgICAgICAgZ290byBmYWlsOworICAgICAgICB9CisK Kwlmb3IoaSA9IDA7aSA8IG5jZWxscztpKyspIHsKKwkJZXJyb3IgPSBjbGtfZ2V0X2J5X29md19p bmRleChkZXYsIG5vZGUsIGksICZjbGspOworCQlpZihlcnJvcikgeworCQkJZGV2aWNlX3ByaW50 ZihkZXYsICJDb3VsZCBub3QgZ2V0IGNsb2NrICMlZFxuIiwgaSk7CisJCQllcnJvciA9IEVOWElP OworCQkJZ290byBmYWlsOworCQkgfQorCisJCWVycm9yID0gY2xrX2VuYWJsZShjbGspOworCQlp ZihlcnJvcikgeworCQkJZGV2aWNlX3ByaW50ZihkZXYsICJDb3VsZCBub3QgZW5hYmxlIGNsb2Nr ICMlc1xuIiwgY2xrX2dldF9uYW1lKGNsaykpOworCQkJZXJyb3IgPSBFTlhJTzsKKwkJCWdvdG8g ZmFpbDsKKwkJIH0KKwl9CisKKwllcnJvciA9IGh3cmVzZXRfZ2V0X2J5X29md19uYW1lKGRldiwg bm9kZSwgInJlc2V0IiwgJmh3cmVzZXQpOworICAgICAgICBpZiAoZXJyb3IgIT0gMCAmJiBlcnJv ciAhPSBFTk9FTlQpIHsKKyAgICAgICAgICAgICAgICBkZXZpY2VfcHJpbnRmKGRldiwgIkNhbm5v dCBnZXQgJ3Jlc2V0JyByZXNldFxuIik7CisgICAgICAgICAgICAgICAgZXJyb3IgPSBFTlhJTzsK KyAgICAgICAgICAgICAgIC8qIGdvdG8gZmFpbDsqLworICAgICAgICB9CisKKyAgICAgICAgaWYg KGh3cmVzZXQgIT0gTlVMTCkgeworICAgICAgICAgICAgICAgIGVycm9yID0gaHdyZXNldF9kZWFz c2VydChod3Jlc2V0KTsKKyAgICAgICAgICAgICAgICBpZiAoZXJyb3IgIT0gMCkgeworICAgICAg ICAgICAgICAgICAgICAgICAgZGV2aWNlX3ByaW50ZihkZXYsICJDYW5ub3QgZGVhc3NlcnQgcmVz ZXRcbiIpOworICAgICAgICAgICAgICAgICAgICAgICAgZ290byBmYWlsOworICAgICAgICAgICAg ICAgIH0KKyAgICAgICAgfQorCisJLyogSW5pdGlhbGl6ZSBjYWxsb3V0ICovCisJY2FsbG91dF9p bml0KCZzYy0+c2Nfcm5ndG8sIENBTExPVVRfTVBTQUZFKTsKKwljYWxsb3V0X3Jlc2V0KCZzYy0+ c2Nfcm5ndG8sIGh6LCBya19ybmdfaGFydmVzdCwgc2MpOworCisJcmV0dXJuICgwKTsKK2ZhaWw6 CisJcmV0dXJuIChlcnJvcik7Cit9CisKK3N0YXRpYyBpbnQKK3JrX3JuZ19kZXRhY2goZGV2aWNl X3QgZGV2KQoreworCXN0cnVjdCBya19ybmdfc29mdGMgKnNjOworCisJc2MgPSBkZXZpY2VfZ2V0 X3NvZnRjKGRldik7CisKKwkvKiBTdG9wIHRoZSBSTkcgKi8KKwlpZihzYy0+c2NfcHN0YXQgIT0g UktfUk5HX1NUT1BQRUQpCisJCXNjLT5zY19jb25mLT5vZmYoc2MpOworCS8qIERyYWluIHRoZSBj YWxsb3V0IGl0ICovCisJY2FsbG91dF9kcmFpbigmc2MtPnNjX3JuZ3RvKTsKKworCS8qIFJlbGVh c2UgbWVtb3J5IHJlc291cmNlICovCisJaWYgKHNjLT5zY19yZXNbMF0gIT0gTlVMTCkKKwkJYnVz X3JlbGVhc2VfcmVzb3VyY2UoZGV2LCBTWVNfUkVTX01FTU9SWSwgMCwgc2MtPnNjX3Jlc1swXSk7 CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgZGV2aWNlX21ldGhvZF90IHJrX3JuZ19tZXRo b2RzW10gPSB7CisJLyogRGV2aWNlIGludGVyZmFjZSAqLworCURFVk1FVEhPRChkZXZpY2VfcHJv YmUsCQlya19ybmdfcHJvYmUpLAorCURFVk1FVEhPRChkZXZpY2VfYXR0YWNoLAlya19ybmdfYXR0 YWNoKSwKKwlERVZNRVRIT0QoZGV2aWNlX2RldGFjaCwJcmtfcm5nX2RldGFjaCksCisKKwlERVZN RVRIT0RfRU5ECit9OworCitzdGF0aWMgZHJpdmVyX3Qgcmtfcm5nX2RyaXZlciA9IHsKKwkicmty bmciLAorCXJrX3JuZ19tZXRob2RzLAorCXNpemVvZihzdHJ1Y3Qgcmtfcm5nX3NvZnRjKQorfTsK KworRFJJVkVSX01PRFVMRShya19ybmcsIHNpbXBsZWJ1cywgcmtfcm5nX2RyaXZlciwgMCwgMCk7 CitEUklWRVJfTU9EVUxFKHJrX3JuZywgb2Z3YnVzLCBya19ybmdfZHJpdmVyLCAwLCAwKTsKK01P RFVMRV9WRVJTSU9OKHJrX3JuZywgMSk7CitNT0RVTEVfREVQRU5EKHJrX3JuZywgcmFuZG9tZGV2 LCAxLCAxLCAxKTsKCg== --b1_d0957a9db152ebc6cc15e86a0f83e5c2-- From nobody Sun Nov 19 00:46:05 2023 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 4SXsQQ5d97z50vmP for ; Sun, 19 Nov 2023 00:46:22 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Received: from mailgate.us (mailgate.us [185.72.246.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4SXsQP2CN5z3PKn for ; Sun, 19 Nov 2023 00:46:21 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Authentication-Results: mx1.freebsd.org; dkim=fail ("body hash did not verify") header.d=mailgate.us header.s=mail header.b=uH3NQ9iw; spf=pass (mx1.freebsd.org: domain of stanislav.silnicki@mailgate.us designates 185.72.246.236 as permitted sender) smtp.mailfrom=stanislav.silnicki@mailgate.us; dmarc=none Received: from localhost (api.telegram.org [192.168.2.1]) by mailgate.us (Postfix) with ESMTPSA id CC1F0A4F51 for ; Sun, 19 Nov 2023 03:46:11 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailgate.us; s=mail; t=1700354773; bh=HaQ+DoXx0hM8UXYf4ADZ9bnakultW7vDZZxRLRUNG2E=; h=From:Subject:To:References:Date; b=uH3NQ9iwcu0jaVTXb5G60uFQfoiJ+XOXNvvNqc164TJtLgNlaMgoqZfg7fK2ErVbC 7yyfrRQR0vs+qkfTVeMuNZfyGgQoPEfhfwSA1z41doptbYR2Tdl3jne/SKwTtwNKs3 NK7TM8Q7Qun2EuAVwZCC0bqDfIEh5T3u9Ws3URS4= Content-Type: multipart/alternative; boundary="----sinikael-?=_1-17003547656200.5932120312415674" From: Stanislav Silnicki Subject: Re: STM32MP157 X-Type: reply To: "freebsd-arm" User-Agent: Desktop Message-Id: <19de1a006e313.760d63ffe37aa@mailgate.us> References: <4d6bf0126f4fb.c24cc5f2fa47c@mailgate.us> <00cab7929791c.8af55c0bd1d5f@mailgate.us> <5d65957f4c04a4bec7ae6ef5469b149c@ohdata.se> <0dab0fc75864.77e1118ea80bb@mailgate.us> <5aa7e3eff95c.2102a80bb1a3b@mailgate.us> <0926803a4f0a.17799edcfe428@mailgate.us> Content-Transfer-Encoding: quoted-printable Date: Sun, 19 Nov 2023 00:46:05 +0000 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 X-Spamd-Result: default: False [0.17 / 15.00]; URI_COUNT_ODD(1.00)[25]; R_DKIM_REJECT(1.00)[mailgate.us:s=mail]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.98)[-0.975]; SUBJ_ALL_CAPS(0.75)[10]; NEURAL_HAM_MEDIUM(-0.41)[-0.415]; R_SPF_ALLOW(-0.20)[+ip4:185.72.246.236/32]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_NO_TLS_LAST(0.10)[]; XM_UA_NO_VERSION(0.01)[]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[mailgate.us:-]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:47447, ipnet:185.72.246.0/24, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[mailgate.us]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4SXsQP2CN5z3PKn X-Spamd-Bar: / ------sinikael-?=_1-17003547656200.5932120312415674 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: 7bit The root cause of zeroed stack in my setup with STM32MP157 seems to be in the TEX remapping registers values, calculated by pmap_set_tex(void). It can be a wrong assumption, as I'm not sure of any hardware (OTP/Security) tunings, that might be in effect.... Blindly copied values for PRRR & NMRR registers from Linux kernel (6.1.28), supplied by STM in their distribution I could avoid the trouble with zeroed stack memory. The hardcoded values are: rg ".equ\s+(PR|NM)RR" arch/arm/mm/* arch/arm/mm/proc-v7-3level.S 110:.equ PRRR, 0xeeaa4400 @ MAIR0 111:.equ NMRR, 0xff000004 @ MAIR1 arch/arm/mm/proc-v7-2level.S 137:.equ PRRR, 0xff0a81a8 138:.equ NMRR, 0x40e040e0 I (wrongly?) assume, 2level is related to the ones, calculated by pmap_set_tex. Narrowing down the inconsistency among values found in Linux kernel and calculated here, I came to the result that the type of inner cache, tuned for first value of tex_classes lut ruins memory: TEX(PRRR_MEM, NMRR_WB_WA, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - zeroes stack mem on TLB flush TEX(PRRR_MEM, NMRR_WB, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - zeroes stack mem on TLB flush TEX(PRRR_MEM, NMRR_WT, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - DOES NOT zeroes stack mem on TLB flush TEX(PRRR_MEM, NMRR_NC, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - DOES NOT zeroes stack mem on TLB flush Need further investigation.... Any clues? Stan Stanislav Silnicki wrote: STM32MP15x port current progress: ... it took some time to solder down the probe and establish conveniences with remote kernel debug... So far, I need to understand, whither or not I face an expected behavior? It looks like tlb_flush_all_local() (https://github.com/freebsd/freebsd-src/blob/525ecfdad597980ea4cd59238e24c8530dbcd31d/sys/arm/arm/pmap-v6.c#L512C14-L512C14) destroys stack memory, where return address is stored, so when stored lr is poped into pc, it is 0x0.... here is a dump of my debug session around that code: 508 cp15_prrr_set(prrr); (kgdb) i f Stack level 0, frame at 0xc0784598: pc = 0xc0557b44 in pmap_set_tex (/usr/src/sys/arm/arm/pmap-v6.c:508); saved pc = 0xc055254c called by frame at 0xc07847e0 source language c. Arglist at 0xc0784590, args: Locals at 0xc0784590, Previous frame's sp is 0xc0784598 Saved registers: r4 at 0xc0784580, r5 at 0xc0784584, r6 at 0xc0784588, r10 at 0xc078458c, r11 at 0xc0784590, lr at 0xc0784594 (kgdb) x 0xc0784594 0xc0784594: 0xc055254c (kgdb) n stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled 509 cp15_nmrr_set(nmrr); (kgdb) x 0xc0784594 0xc0784594: 0xc055254c (kgdb) n stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled 512 tlb_flush_all_local(); (kgdb) x 0xc0784594 0xc0784594: 0xc055254c (kgdb) si stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled _CP15_TLBIALL () at /usr/src/sys/arm/include/cpu-v6.h:147 147 _WF0(_CP15_TLBIALL, CP15_TLBIALL) /* Invalidate entire unified TLB */ (kgdb) si stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled tlb_flush_all_local () at /usr/src/sys/arm/include/cpu-v6.h:340 340 dsb(); (kgdb) x 0xc0784594 0xc0784594: 0x00000000 (kgdb) si stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513 513 } (kgdb) si Polling target stm32mp15x.cm4 failed, trying to reexamine Failed to read memory at 0xe000ed00 Examination failed, GDB will be halted. Polling again in 100ms Program stopped. pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513 513 } (kgdb) The address, referenced from error message (0xe000ed00) is mapped by STM's address space to "DDR extension (CA7 only) or Debug" with debug assigned to Cortex-M4 coprocessor. I'm not sure, that it is an unexpected behav. (it is my first attempt to port to armv7), so need an advice. Any? Stan Stanislav Silnicki wrote: my current progress of STM32MP1xx port attempt: Basically, both options to boot ubldr and then kernel in SPL & TF-A modes of u-boot are supported. Initially, when I stated from TF-A options (security supervision from arm's trusted firmware os) I stuck with this line: https://github.com/freebsd/freebsd-src/blob/501bdf3001190686bf55d9d333cb533858c2cf2f/sys/arm/arm/locore-v6.S#L371 control does not seem to reach beyond that point. I tried to enable the led with this assembly, which works anywhere else: /* prepare to use LED @ GPIOA 13*/ ldr r0, =0x50002014 ldr r1, =0xFFFFDFFF ldr r2, [r0] and r2, r1, r2 /* Enable caches. */ mrc CP15_SCTLR(r7) orr r7, #CPU_CONTROL_DC_ENABLE orr r7, #CPU_CONTROL_IC_ENABLE orr r7, #CPU_CONTROL_BPRD_ENABLE mcr CP15_SCTLR(r7) DSB /* turn on GPIO LED */ str r2, [r0] Control passes if I disable data cache ORing instruction, but then hangs on setting of new TTB couple lines below... I thought it was due to security access control from TF-A, but it behaves the same w/o. Any clues or expertise from other platforms are highly appreciated. Stan Stanislav Silnicki wrote: Hello, I need an advice on the intial addresses layout when booting the kernel. As I understand, ubldr is the proper way to boot the kernel. What is the correct address to load it, given that I wand to keep default KERNVIRTADDR (=0xc0000000) intact? The u-boot loads ubldr this way in my current setup: // FreeBSD version of environment env_set("baudrate", "115200"); env_set("console", "ttyS0,115200"); env_set("stderr", "serial"); env_set("stdin", "serial"); env_set("stdout", "serial"); env_set("autostart", "yes"); env_set("loaderdev", "mmc 1"); // fbsd's ubldr treats our second mmc at index 1 env_set("bootcmd", "fatload mmc 2 0xc0000000 ubldr && bootelf"); then ubldr leads the kernel from mmc and passes it the control: Loading kernel... /boot/kernel/kernel text=0x1b4 text=0x5b8530 text=0x17d91c data=0xa4a60 data=0x0+0x20c000 0x4+0x88810+0x4+0xe9d98| Loading configured modules... can't find '/boot/entropy' can't find '/etc/hostid' Using DTB compiled into kernel. Kernel entry at 0xc0400200... Kernel args: (null) Then I could correctly pass the init of MMU and get into translated mode only with setting KERNVIRTADDR = 0xc4000000. It looks like kernel and loader clash somehow. So, just need to understand what is best option to load ubldr to? Will it affect further routines? Stan Stanislav Silnicki wrote: OK, I got the idea! As I realize, there is a minor bug in dtc, which affects compilation of stm's originated DTBs. I think it is best to make a PR into https://github.com/davidchisnall/dtc, which I'm discussing with repo owner already. Please tell me, that I need to post PR into FBSD source tree if it is a shorter way for my fix. My current setup is based upon QBASE1 from Karo-Electronics, but there is no goal to support/debug all peripherals, only a subset, including USB, I2C, SDMMC, DSI (and GPU, if lucky). https://www.karo-electronics.com/fileadmin/download/Datasheets/QSMP-QSBASE1-Evalkit.pdf The vendor (Karo) supports only their Yocto based Linux distro. I spent some time to prepare TF-A & Uboot, capable with booting from SD card (that is more robust approach, as I think). STM does not promote/support non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it is pretty cumbersome path, I had to pass. I think, it will be easier for me to prepare some sort of README to support customization of uboot for STM's port and dig it somewhere in SRC rather than ; ; ; ;try to post PR's in those repos... Not sure, anyway. So far I'm struggling with uart and early_printf... I'm mixing this activity with my current occupation, so I don't expect rapid progress. Thank you for clarifications! I'll try to do my best! Stan Oskar Holmlund wrote: Hi Stanislav, Please resend your message and CC the arm mailing list. It might be interesting for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think you stopped working on the STM32 port. You should always keep one terminal up n running % man 9 style :) https://wiki.freebsd.org/Phabricator will give you some information. Its good if you get to know the people active in the ARM area, just keep an eye on the mailinglist and you will notice some names. If you have the opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even more people. Join the IRC, for example on efnet #bsdmips is a good channel for ARM stuff. Start with small changes and you will get feedback. From there the experience will grow and you will get into it all. Correct, the device-tree import is from the Linux kernel and there is no prior work for the STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD either. Probably because the STM32MP15 is the first(?) application SoC from ST? 1) hum? Do you need that for the reviews? It should be in SRC 2) Target branch is probably main. 3) It depends, if your custom board is opensource and availble around the globe through mouser/farnell/.. I dont see any problem. Otherwise pick the board from ST that you used as a reference when you developed the custom board. For example in my day job we have a custom board built around the octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black wifi. So the code thats goes into the FreeBSD project are all tested on the beaglebone boards. The stuff we need for our custom board like the device tree is keept as local patches in our inhouse build process. //Oskar 2023-10-28 14:25 skrev Stanislav Silnicki: Hi Oskar! > can you point me some guidelines to help myself to fit development process? I'm sure, there is mature dev. culture around FBSD and I'd be happy to make my contribution coherently from the beginning. > So far I'm done with setup of my account at reviews (keys, 2FA, etc.) > As I understand, there is no considerable progress with STM32, although I have noticed, there are some DTS imported into the project. > > Indeed, several major questions: 1. repo url? 2. tagret branch for patches for stm32 hw? 3. is it possible to target custom board from our project, or I have to ensure support for all dev. boards, provided by STM? > Thank you,Stan > Oskar Holmlund wrote: >> 2023-10-27 22:33 skrev Stanislav Silnicki: >>> Hello! I'm porting onto the subject hardware. So far the progress is modest, while the system boots (without console although...) One of major issues is hardcoded value inside locore-v6.S. Here is my relevant post: >> > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438 [1] What is the best way to proceed? Patch, vendor kernel build, something else? Stan > Links: ------ >> [1] > > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438 >> Hi Stan, >> Upload your patch to reviews.freebsd.org >> Love to see your other patches for the STM32MP15x. kquote> > //Oskar ------sinikael-?=_1-17003547656200.5932120312415674 Content-Type: text/html; format=flowed Content-Transfer-Encoding: 7bit
The root cause of zeroed stack in my setup with STM32MP157 seems to be in the TEX remapping registers values, calculated by  pmap_set_tex(void). It can be a wrong assumption, as I'm not sure of any hardware (OTP/Security) tunings, that might be in effect....

Blindly copied values for PRRR & NMRR registers from Linux kernel (6.1.28), supplied by STM in their distribution I could avoid the trouble with zeroed stack memory. The hardcoded values are:
rg ".equ\s+(PR|NM)RR" arch/arm/mm/*
arch/arm/mm/proc-v7-3level.S
110:.equ PRRR, 0xeeaa4400 @ MAIR0
111:.equ NMRR, 0xff000004 @ MAIR1

arch/arm/mm/proc-v7-2level.S
137:.equ PRRR, 0xff0a81a8
138:.equ NMRR, 0x40e040e0

I (wrongly?) assume, 2level is related to the ones, calculated by pmap_set_tex.

Narrowing down the inconsistency among values found in Linux kernel and calculated here, I came to the result that the type of inner cache, tuned for first value of tex_classes lut ruins memory:

TEX(PRRR_MEM, NMRR_WB_WA,    NMRR_WB_WA, 0),  /* 0 - ATTR_WB_WA */ - zeroes stack mem on TLB flush

TEX(PRRR_MEM, NMRR_WB,    NMRR_WB_WA, 0),  /* 0 - ATTR_WB_WA */ - zeroes stack mem on TLB flush
TEX(PRRR_MEM, NMRR_WT,    NMRR_WB_WA, 0),  /* 0 - ATTR_WB_WA */ - DOES NOT zeroes stack mem on TLB flush
TEX(PRRR_MEM, NMRR_NC,    NMRR_WB_WA, 0),  /* 0 - ATTR_WB_WA */ - DOES NOT zeroes stack mem on TLB flush

Need further investigation....
Any clues?

Stan

Stanislav Silnicki wrote:

STM32MP15x port current progress:

... it took some time to solder down the probe and establish conveniences with remote kernel debug...

So far, I need to understand, whither or not I face an expected behavior?

It looks like tlb_flush_all_local() (https://github.com/freebsd/freebsd-src/blob/525ecfdad597980ea4cd59238e24c8530dbcd31d/sys/arm/arm/pmap-v6.c#L512C14-L512C14)
destroys stack memory, where return address is stored, so when stored lr is poped into pc, it is 0x0....

here is a dump of my debug session around that code:

508 cp15_prrr_set(prrr);
(kgdb) i f
Stack level 0, frame at 0xc0784598:
 pc = 0xc0557b44 in pmap_set_tex (/usr/src/sys/arm/arm/pmap-v6.c:508); saved pc = 0xc055254c
 called by frame at 0xc07847e0
 source language c.
 Arglist at 0xc0784590, args: 
 Locals at 0xc0784590, Previous frame's sp is 0xc0784598
 Saved registers:
  r4 at 0xc0784580, r5 at 0xc0784584, r6 at 0xc0784588, r10 at 0xc078458c, r11 at 0xc0784590, lr at 0xc0784594
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) n
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
509 cp15_nmrr_set(nmrr);
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) n
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
512 tlb_flush_all_local();
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
_CP15_TLBIALL () at /usr/src/sys/arm/include/cpu-v6.h:147
147 _WF0(_CP15_TLBIALL, CP15_TLBIALL) /* Invalidate entire unified TLB */
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
tlb_flush_all_local () at /usr/src/sys/arm/include/cpu-v6.h:340
340 dsb();
(kgdb) x 0xc0784594
0xc0784594: 0x00000000
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513
513 }
(kgdb) si
Polling target stm32mp15x.cm4 failed, trying to reexamine
Failed to read memory at 0xe000ed00
Examination failed, GDB will be halted. Polling again in 100ms

Program stopped.
pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513
513 }
(kgdb) 

The address, referenced from error message (0xe000ed00) is mapped by STM's address space to "DDR extension (CA7 only) or Debug" with debug assigned to Cortex-M4 coprocessor.

I'm not sure, that it is an unexpected behav. (it is my first attempt to port to armv7), so need an advice.
Any?

Stan


Stanislav Silnicki wrote:

my current progress of STM32MP1xx port attempt:

Basically, both options to boot ubldr and then kernel in SPL & TF-A modes of u-boot are supported.

Initially, when I stated from TF-A options (security supervision from arm's trusted firmware os) I stuck with 

control does not seem to reach beyond that point. I tried to enable the led with this assembly, which works anywhere else:

    /* prepare to use LED @ GPIOA 13*/
    ldr r0, =0x50002014
    ldr r1, =0xFFFFDFFF
    ldr r2, [r0]
    and r2, r1, r2

/* Enable caches. */
mrc CP15_SCTLR(r7)
orr r7, #CPU_CONTROL_DC_ENABLE
orr r7, #CPU_CONTROL_IC_ENABLE
orr r7, #CPU_CONTROL_BPRD_ENABLE
mcr CP15_SCTLR(r7)
DSB

    /* turn on GPIO LED */
    str r2, [r0]

Control passes if I disable data cache ORing instruction, but then hangs on setting of new TTB couple lines below...

I thought it was due to security access control from TF-A, but it behaves the same w/o.

Any clues or expertise from other platforms are highly appreciated.

Stan

Stanislav Silnicki wrote:

Hello, I need an advice on the intial addresses layout when booting the kernel.

As I understand, ubldr is the proper way to boot the kernel.
What is the correct address to load it, given that I wand to keep default KERNVIRTADDR (=0xc0000000) intact?

The u-boot loads ubldr this way in my current setup:

  // FreeBSD version of environment
  env_set("baudrate", "115200");
  env_set("console", "ttyS0,115200");
  env_set("stderr", "serial");
  env_set("stdin", "serial");
  env_set("stdout", "serial");
  env_set("autostart", "yes");
  env_set("loaderdev", "mmc 1"); // fbsd's ubldr treats our second mmc at index 1
  env_set("bootcmd", "fatload mmc 2 0xc0000000 ubldr && bootelf");

then ubldr leads the kernel from mmc and passes it the control:

Loading kernel...
/boot/kernel/kernel text=0x1b4 text=0x5b8530 text=0x17d91c data=0xa4a60 data=0x0+0x20c000 0x4+0x88810+0x4+0xe9d98|
Loading configured modules...
can't find '/boot/entropy'
can't find '/etc/hostid'
Using DTB compiled into kernel.
Kernel entry at 0xc0400200...
Kernel args: (null)

Then I could correctly pass the init of MMU and get into translated mode only with setting KERNVIRTADDR = 0xc4000000. It looks like kernel and loader clash somehow.

So, just need to understand what is best option to load ubldr to? Will it affect further routines?

Stan


Stanislav Silnicki wrote:


OK, I got the idea!

As I realize, there is a minor bug in dtc, which affects compilation of stm's originated DTBs. I think it is best to make a PR into https://github.com/davidchisnall/dtc, which I'm discussing with repo owner already. Please tell me, that I need to post PR into FBSD source tree if it is a shorter way for my fix.

My current setup is based upon QBASE1 from Karo-Electronics, but there is no goal to support/debug all peripherals, only a subset, including USB, I2C, SDMMC, DSI (and GPU, if lucky).

The vendor (Karo) supports only their Yocto based Linux distro. I spent some time to prepare TF-A & Uboot, capable with booting from SD card (that is more robust approach, as I think). STM does not promote/support non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it is pretty cumbersome path, I had to pass. I think, it will be easier for me to prepare some sort of README to support customization of uboot for STM's port and dig it somewhere in SRC rather than  ; ; ; ; ;try to post PR's in those repos... Not sure, anyway.

So far I'm struggling with uart and early_printf...

I'm mixing this activity with my current occupation, so I don't expect rapid progress.

Thank you for clarifications! I'll try to do my best!

Stan

Oskar Holmlund wrote:


Hi Stanislav,

Please resend your message and CC the arm mailing list. It might be interesting for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think you stopped working on the STM32 port.

You should always keep one terminal up n running % man 9 style :)
https://wiki.freebsd.org/Phabricator will give you some information.
Its good if you get to know the people active in the ARM area, just keep an eye on the mailinglist and you will notice some names. If you have the opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even more people.
Join the IRC, for example on efnet #bsdmips is a good channel for ARM stuff.

Start with small changes and you will get feedback. From there the experience will grow and you will get into it all.

Correct, the device-tree import is from the Linux kernel and there is no prior work for the STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD either.
Probably because the STM32MP15 is the first(?) application SoC from ST?


1) hum? Do you need that for the reviews? It should be in SRC
2) Target branch is probably main.
3) It depends, if your custom board is opensource and availble around the globe through mouser/farnell/.. I dont see any problem. Otherwise pick the board from ST that you used as a reference when you developed the custom board.
For example in my day job we have a custom board built around the octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black wifi. So the code thats goes into the FreeBSD project are all tested on the beaglebone boards. The stuff we need for our custom board like the device tree is keept as local patches in our inhouse build process.

//Oskar

2023-10-28 14:25 skrev Stanislav Silnicki:

Hi Oskar!
> can you point me some guidelines to help myself to fit development
process? I'm sure, there is mature dev. culture around FBSD and I'd be
happy to make my contribution coherently from the beginning.
> So far I'm done with setup of my account at reviews (keys, 2FA, etc.)
> As I understand, there is no considerable progress with STM32,
although I have noticed, there are some DTS imported into the project.
> > Indeed, several major questions:
1. repo url?
2. tagret branch for patches for stm32 hw?
3. is it possible to target custom board from our project, or I have
to ensure support for all dev. boards, provided by STM?
> Thank you,Stan
> Oskar Holmlund wrote:
>> 2023-10-27 22:33 skrev Stanislav Silnicki:

quote class="gmail_quote" type="cite" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>>> Hello!


I'm porting onto the subject hardware. So far the progress is
modest,
while the system boots (without console although...)
One of major issues is hardcoded value inside locore-v6.S. Here
is my
relevant post:
>> > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
[1]
What is the best way to proceed? Patch, vendor kernel build,
something
else?
Stan



> Links:

------
>> [1] >
> https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
>> Hi Stan,
>> Upload your patch to reviews.freebsd.org
>> Love to see your other patches for the STM32MP15x.

kquote>

>> //Oskar
------sinikael-?=_1-17003547656200.5932120312415674-- From nobody Sun Nov 19 13:44:42 2023 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 4SYBhb3FPXz51nnf for ; Sun, 19 Nov 2023 13:44:47 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4SYBhZ3rfCz3PcF for ; Sun, 19 Nov 2023 13:44:46 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm1 header.b=goYZoNV4; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="yez/wrO8"; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.26 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C53F25C0239 for ; Sun, 19 Nov 2023 08:44:45 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 19 Nov 2023 08:44:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm1; t=1700401485; x=1700487885; bh=gHpj+7efTtzKrQSNsQ4OqSpNd gylmq+jTT4VdXQybLI=; b=goYZoNV4UW+QAZLFzKFrQ0KwWjrGHK8izDbU1vYGB /GFvI8r4wCtuLO8CeC9rvSBh8RsYpVZSv4eKkLogxVMpOlSvWl+farlDINXeUvNc RkjXlVZniSlgv3OLfVXR0TqfUbilQb/YoCHaLxb5nQIn5DAfFrKYWLyFT1gBJhUE FR9j4EHBSBN1VJXv6cx4zcQMLMgj2Iz74lQbE6GkRfYbpJfMa0B1hmsUZLD+GWmJ cGAZdc6YI8tLtd5I6kQxIrQUdUUU8Cf6vBBkXH5y3CnVB9cQMokaLvbbcSiaiGol Ab/t9i/dWwZ0DeIfyr7Y85SEuVAYnbv3mFCgIUv8eBJuw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700401485; x=1700487885; bh=gHpj+7efTtzKrQSNsQ4OqSpNdgylmq+jTT4 VdXQybLI=; b=yez/wrO8EacQZ6OLVf8A3SmuKY1Spvmv1m51l1mTwC2nSOvUznF DmARl9tA5gEVRcRraEoSB88atoObu49LxQl8Lek2Cx8S8aTDtg613Ye+r7XCNziC iwbl3t1WO9/h4lz3srJj621ZIPbx/DPIH36Hwj6jVjvCiihqE7q1FJSV9UjCWwwB Zw1X1GaRaPqK3WpZASJ5YTjjw9mQ3bor/g05kCudCp9wMjeyrwQtIPUwt78fmkDy S+S96EplPvfxrugHSwlrqvSvmWzDtShQJE63LlnD4hD9SiyfNcKBHhmtyOS8VIjI Cmpwc0DDKURmSySUGjk0Fk+cmkxVBZRERig== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeggedgheejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepkeefudfggfeiueeiffehgfdvffejuddvhfdvieefledvjedthfdvheejhffgle eunecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 19 Nov 2023 08:44:45 -0500 (EST) Date: Sun, 19 Nov 2023 13:44:42 +0000 From: void To: freebsd-arm@freebsd.org Subject: pkgs for FreeBSD:14:aarch64 latest are stale compared to quarterly Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org 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=us-ascii; format=flowed Content-Disposition: inline X-Spamd-Result: default: False [-4.70 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.26:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4SYBhZ3rfCz3PcF X-Spamd-Bar: ---- http://pkg.freebsd.org/FreeBSD:14:aarch64/latest/meta.txz is dated 2nd Nov http://pkg.freebsd.org/FreeBSD:14:aarch64/quarterly/meta.txz is dated 15th Nov -- From nobody Sun Nov 19 14:28:18 2023 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 4SYCg7671Rz51rTH for ; Sun, 19 Nov 2023 14:28:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204]) (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 4SYCg72qmtz3V0P for ; Sun, 19 Nov 2023 14:28:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1700404111; bh=lmTL6Huv3vHtonnZmH6TRKZYkQbsyudE+z5vE5UZOAw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=aA2xnqdrCoz6fr9mRP8fpIAk3mueeR2DEdmz8+Dsbh4h/Pa7BGBkeLOKiRM4tmCSDNVrkIA3pI3uctuhtWF60aYY52MstMJfXT1uw9hJpp9QZ+3mub8mR4Ff9VXv1maSwDfEKB/g5nbOTQayNi0QOOU+QhAf3TGKx46B6pyVCqDLVor16WSKj9pdM5cJZHSWm0rqAinGOXIwkYLK7KysE9WVOlH7cR6n5J1buZYmDVp+7qJkQxs3v4IAW4zMLJuvqCZXyARZ9ZrlzhRhKnmdRnH/Nb5Kh8NYjg+GwORxEigymcZTf+gaQ6KjvzCQid7Lze32M6uMrFwsLadvUnFgKQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1700404111; bh=AB4LaESIFN4mE2BZoqLgNs8czl8dJb1TYkuWrYTZ4kh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=o3okHj7NAp0C7yN09ch/mGessgdUcxUa1c+MY/o9PBDDXk35WoImjsHAk/dxngRmY/F0zu0dcu8/U1XEQhLIRIPQwhHZ2obveGqmCXyP1jLne5BGjiHxoEpxWK0OMhRTonGao6xdxKBIfx3+i1wDs9ZuS+UpIvZoUbNHCJ5pdo0PnPW7AX2F4jpyqLr6pxwO+SBguSBkahLHcotteFlJP9eXxBCN7vMDucqAjUTLrGD1PfQsGXR9msCb+cLSYvozy75tyWmBWtJ4ogLlsnKHC/VntJ70hY22r4uDZ0LSm71FZXvZ9zd0rR/sf6+FUG9d/pWOvH8mdIJnyDeapcsIsg== X-YMail-OSG: EXlAclsVM1lO1gLQ9BB1BsLvYfB1csPR9_aMFQxXaxBgoRlmLYktWwwnkQBcG0g bUxB30MlF27lTHUPFOC4DqaGqHTx3cepxM6ehyctB.lNyRi8sVZ71CIs4oPjyxPLxxjBdzCIVrrJ n9tmxslSDWhfk3Q5iPicyWbyD8JyG0BMbL1u9GZmZgXUOrGAwxu5PtJ2s8X9SA.ABBPZ3zgbAHVW HNBxf80kYdz8gMZBnv1Kacm1BilBgc.kORdb1XnKasAXAfejOziAFmbyzlbBlhwiqaPxroYUsVUJ OrfArxIN1WPEOd3wZ8MhfZHxNlWgut9Mqk5b4X6jgQE6z8caAzsR14A7V.gjZvuFvuDX.QmSuE3O DRbo07vr9vjRXuxoIUW5aUFUgY6z93PO4j3_P33wr28oIDnF2yW6.PYI_naI4msXB7TRGkGPp4Bc 17o0n1F9TSzc4uLnUG00xUK4x6HbfIcjeifLLURbZu240yaiApVDwV_kY9_EQDh8e3_nRShq_Jcx Yh8zpJkBC3rGm3Ujyg1AiiXH3AFcoNBROahC19giWXtRXekF0fLRnh65BwfDo.IuP1mLJYOCA2EU dLzmmUpnA5KDguDhFCoTeiy9PHp3D34wgQtgaHH.cCE8dUFyJc0aWqUMeDLazP2BIxWxcQi5Ug8_ e1Y9VcC_skeHiJxtaGIrGMegALbLOu3M4fIKhK20RsM7lyu8CAAVrP4qVPyXuc3SlyvvcEY6VmWi nTZofAKDVkBW_6DhJGf9ztnpByECDAe5nWvlvDGL5xgary8lpQud4VYCpJhQwSnMitldfZ0oyTww TeS32PQxOEBOEWm67tXD.lYJsEwa1dj.APBAk6DxvC6PI5Mf5z_6CgPTaKZ1hPbN0ktJCfopK0OM KpJK0pRwnWiB.s_Hz6EvtR1fZJwCtiYt8BuyFq15WABRW.qjUc7rUeF.B0B7IOWJpUCY0UV4.Q90 3jKuD3uPHm.19vtXPDO51dG86NutlkD41mUC5yX1sGhnqNHeUQkWTeg.ZdbJ.6a7jMtDUrOKyGeI 3pA3UKDrldUT6oA.vVV2TlCN8quo2R6vJTxvx0ty0Qizi_HBUE3fYGjFtmRAWezGI5sTH0M7RkL0 UCVqb8FfOHD4yovLRt4OYUVZalz2NMHTnE.6dtotl5jqU2wKm6EYQhiBOA0LRinydPQ3t5vpGNGt L7Rsb.4umihnKaWfpZATftciBqvg2U.p1A._B3UWhtZCXjuyMRhKIvCUtIXUQxF526vAhwlutI1E BPADXnQWhnErNSKVa0RYuZGenZALLa_XU85DLFI0P7wwgvBijXYImr_7u4uXWJJJba6mDcIvjAIz TFEyIEy35qa7bF7cqZ9sIi9rqPPQLaC4bKIYk98LA90UAhTwC4v96morMYt8Pb5o.txwpgdfH8z. F7x9hXBxqdF1NTi7IGtKJJ6O7Am86xHyTrUu1W4IKDseD1D_7bUe46VNMs9ma2sj5wZYTWcTe5ns arH6BI..mRtU6tkTDY1j_44XqL36oU8XLxQyDYvyvfSe9G8Ip7ubTwJKU5MQuD94irgj3K0xBqID pZcjoddCBjCdIKAl5KYPx9BzX7P7ATGCcn7nUzpUdrpdLniRkRqHHngK1B6NQIzY_uC_voMvRyDy YDNC8qQnePR.HrPZo2o3aOKxLiYfh0KK0A8IM4CeYZn4JnFSuh15fvZQKVMy2vX.lr9EXDmkHgOf oplPi8IwNKIld47dSLhTPOm9yh7oE5kB6hYZYR0X0LeEuCLzYkGQFDB2O7QGJpaSOsjYutbsPnjb LCnwJGyTgr1uQDz7RrLWzMrwzuhA8LQJaLHM6fnUqDsNVal_ICnbNELwmO4DwoUE3FKlkxXxe1eD GZglxnF4Y1pMTXaKjmpPi8uAMMvhczHGzpBxKU4qf0RAPl4jvRBd11UmVZNMH.cIiyHBx3YvGhGf GBgFFaEeaZ6SJiAAerDFl2GVYRNBDYLQK4CkazyZfDJRkxjdWEwAZna4cbu5Kki8oz8735_ofoyY vwf.iihCBtjPNaUJyKuVY0dJ91n_XWFsy7GNO3SzjDiTFtVSAoIS17Kc.VW9ZmrcQvqDpWF3hVnx GCu1p8afltfRLCIYiTZRBoBK9BQphwwyittN3_upnnWRbvSgPXHj487xGmWvUn1EmDJVVq8SMbjE 0K3VBwZ3QNsVm.w3bVgyAvmRRe_qwWs4zRdcruMGPbek8Z71FepEZX88xo1z080wheMys__yMrtx 0sOF.9VAGfZPn6Ge17SMTM8KFA4ZrkXR7tnBTr_S11Ek0jeu0SNAyUgp6orqz3OBmPkKJKU3A.iZ _Kg-- X-Sonic-MF: X-Sonic-ID: 92f59408-a910-4949-9a89-078c8cca4260 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Nov 2023 14:28:31 +0000 Received: by hermes--production-gq1-59b5df67b6-72bc4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0c7a54dbaa2f136afc2baacd921a888a; Sun, 19 Nov 2023 14:28:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: pkgs for FreeBSD:14:aarch64 latest are stale compared to quarterly From: Mark Millard In-Reply-To: Date: Sun, 19 Nov 2023 06:28:18 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <49AAADF7-2A14-4922-AC56-B763EF0C6FB1@yahoo.com> References: To: void X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4SYCg72qmtz3V0P On Nov 19, 2023, at 05:44, void wrote: > http://pkg.freebsd.org/FreeBSD:14:aarch64/latest/meta.txz is dated 2nd = Nov > http://pkg.freebsd.org/FreeBSD:14:aarch64/quarterly/meta.txz is dated = 15th Nov Note: The below does not deal with time to distribute packages after the overall build completes. The dates show are start dates, so the start of the next build gives about the time of the finish of the prior build. This is perfectly normal, as shown by: ampere3 built/is-building (in seqeuence, build start dates): (some are from scratch "bulk -a"s and others are incremental) Sat, 28 Oct 2023 17:19:57 GMT default (a.k.a. latest) 140releng-arm64 Thu, 02 Nov 2023 10:13:56 GMT default (a.k.a. latest) 140releng-armv7 Tue, 07 Nov 2023 03:52:04 GMT default (a.k.a. latest) 132arm64 Sat, 11 Nov 2023 15:39:17 GMT default (a.k.a. latest) 132releng-armv7 Tue, 14 Nov 2023 11:03:37 GMT default (a.k.a. latest) 140releng-arm64 Sat, 18 Nov 2023 21:48:56 GMT default (a.k.a. latest) 140releng-armv7 ampere1 built/is-building (in seqeuence, build start dates): (some are from scratch "bulk -a"s and others are incremental) Fri, 27 Oct 2023 04:07:35 GMT quarterly 140releng-arm64 Tue, 31 Oct 2023 16:08:09 GMT quarterly 140releng-armv7 Sat, 04 Nov 2023 03:47:53 GMT quarterly 132arm64 Mon, 06 Nov 2023 16:45:04 GMT quarterly 124arm64 Thu, 09 Nov 2023 08:56:56 GMT quarterly 132releng-armv7 Sat, 11 Nov 2023 01:58:53 GMT quarterly 140releng-arm64 Wed, 15 Nov 2023 19:54:05 GMT quarterly 140releng-armv7 Sun, 19 Nov 2023 03:50:25 GMT quarterly 132arm64 So: For (only) 140releng-arm64 the finished-dates look like: 31 Oct 2023 finish quarterly 02 Nov 2023 finish default (a.k.a. latest) 15 Nov 2023 finish quarterly 18 Nov 2023 finish default (a.k.a. latest) The relative offsets in timing need not be stable over time. But having a range of days with weeks between the quarterly and default (a.k.a. latest) most-recent builds of 140releng-arm64 is perfectly normal. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Nov 19 16:04:39 2023 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 4SYFp42cPhz50ykn for ; Sun, 19 Nov 2023 16:04:44 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4SYFp33KdQz3fxk for ; Sun, 19 Nov 2023 16:04:43 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm1 header.b=LkPMR7jA; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=hi1kuqjt; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.29 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6162A5C01D6 for ; Sun, 19 Nov 2023 11:04:42 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 19 Nov 2023 11:04:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1700409882; x=1700496282; bh=ye ZrP4arUqW3y45RME0Ak7yt+w8YB5a3oLCfN7BjYsg=; b=LkPMR7jA21hZsTE3Xy dHeAXdRco3aHsSymSgqNh/YRbBJIpiask0twHXDajuHfX6JyysaWvGO097cHoDxy RYZgWtY25f+enYrNm0rIJ0/xcYnXgtrLPPQC1GneIEjuRDGw3Sr5QBghJXdMP0C/ C93YO0fkKFslHzdDfTyqBML4JuXUSLgyZl+PNOqkVAwCQl5fCaYHTGvDU866DH1a dl5fJVZch+WaBV3V0r0+snkgZb7KKHEWv8DP1vDwnvpVF/fRNHVjyPq9FFFsXMHO X1H1r6N+fwfTqx0BxOVOKM5N9gpB8DeMKm6BjpQLryPNyI275MGbDPY/yJi49tN3 aVBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1700409882; x=1700496282; bh=yeZrP4arUqW3y 45RME0Ak7yt+w8YB5a3oLCfN7BjYsg=; b=hi1kuqjtfHkB2ctOMmeLQy0t+oYL/ nw1DECwckDCdc1edjTUlVvhlIQu0GKyL4HO9YRcMNSpaIgtf7qJhecSkuJGqT/yx EhaAn1kaywxjzXd/Dyp5IJyvtT/hLZ1evO8QVcVL3Nmv5wJ7X2VaB1Tg/t/CADPE xytuWZPt2FagQkov7sh+eAyCHkXfuFIegX8GO/Wbp/5tMQRcjz+kii7Z/LCmQZpE p2zIBG8xZEeSbmIzWK00rV86g8ahbtwGPVCTvcT+rIKk8UI4U5CfvwAtm2dX/f9d M++Iu0+2VxiLEBrdTliMLDCTe2QEdjB5yUc2Xk4tB9SWrOVI5mBHB9sWQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeggedgkeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnheptdfhheeuteejudffkefhtdfhfeekgedtvdeiteevgfejtdfgfeffhfeuie eltdeinecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 19 Nov 2023 11:04:41 -0500 (EST) Date: Sun, 19 Nov 2023 16:04:39 +0000 From: void To: freebsd-arm@freebsd.org Subject: Re: pkgs for FreeBSD:14:aarch64 latest are stale compared to quarterly Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <49AAADF7-2A14-4922-AC56-B763EF0C6FB1@yahoo.com> 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=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <49AAADF7-2A14-4922-AC56-B763EF0C6FB1@yahoo.com> X-Spamd-Result: default: False [-4.88 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.88)[-0.876]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[66.111.4.29:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4SYFp33KdQz3fxk X-Spamd-Bar: ---- Hi Mark, (have replied to your reply inline) I don't want to give the impression that I'm foot-tapping impatiently for the latest pkg builds. The reason behind the query was because there are several ports affected by vulns between say 31st Oct and now. I was looking to see if there were updates available in pkgs. Found there weren't, checked and the system was using "latest", so had to build directly from the ports tree which was suboptimal on this hardware. Nevertheless, they all built, the software is up-to-date and that problem is solved. Meanwhile, checked to find the timestamp of 'latest' and found it was 02 Nov, which was surprisingly ancient to me. I thought maybe there was something wrong with the/a builder? So checked this against quarterly, and found quarterly timestamped 2 weeks later than 'latest'. On Sun, Nov 19, 2023 at 06:28:18AM -0800, Mark Millard wrote: >On Nov 19, 2023, at 05:44, void wrote: > >> http://pkg.freebsd.org/FreeBSD:14:aarch64/latest/meta.txz is dated 2nd Nov >> http://pkg.freebsd.org/FreeBSD:14:aarch64/quarterly/meta.txz is dated 15th Nov > >Note: The below does not deal with time to distribute >packages after the overall build completes. The dates >show are start dates, so the start of the next build >gives about the time of the finish of the prior build. (snip) >So: For (only) 140releng-arm64 the finished-dates look like: > >31 Oct 2023 finish quarterly >02 Nov 2023 finish default (a.k.a. latest) >15 Nov 2023 finish quarterly >18 Nov 2023 finish default (a.k.a. latest) so, approx 3 days for a build, if the machine builds quarterly=>latest=>quarterly. Latest completed on the 18th. It's the 19th now (1533 UTC) and both http://pkg0.nyi.freebsd.org/FreeBSD:14:aarch64/latest/meta.txz and http://pkg0.fra.freebsd.org/FreeBSD:14:aarch64/latest/meta.txz are dated 02 Nov. How long would you expect it to take for pkgs to be distributed? >The relative offsets in timing need not be stable over time. >But having a range of days with weeks between the quarterly >and default (a.k.a. latest) most-recent builds of >140releng-arm64 is perfectly normal. I'm with you WRT days, and also days or weeks WRT quarterly lagging latest - but weeks where latest lags quarterly? Maybe my idea/usage of the terms 'quarterly' and 'latest' are different to FreeBSD's. In terms of time, my usage of 'quarterly' means 'about every three months'. So I'd think it reasonable to think that, in the context, 'quarterly' would mean a datestamp from now to three months ago. But never more than a few days more recent than latest, unless there was a problem in building or distributing packages. I thought there might be a problem, hence the original email. -- From nobody Sun Nov 19 16:12:55 2023 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 4SYFzZ5mvRz510L0 for ; Sun, 19 Nov 2023 16:12:58 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SYFzZ2Wfdz3grB for ; Sun, 19 Nov 2023 16:12:58 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm1 header.b=Cm9sYFTF; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=h70RPpcw; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.29 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3FA4C5C010B for ; Sun, 19 Nov 2023 11:12:58 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 19 Nov 2023 11:12:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1700410378; x=1700496778; bh=Ou wMnI0vcYFpT9C1PoVpbOVTOl+shh447C2TOvEG3WE=; b=Cm9sYFTFAINuQc6QYc wNaUtXJWmmmpXTOqGmm5VB3B2QIDYsd1ob9/u9aZS4dAyjw6y/z9oo7p0ddQPIG/ ZqWFb6j3jHfidxdtmNOfiesHhC6qZCbEUAUncnJBU18NJXYtjmB02Wan0WMxzLns 2wziWfdP4bYAuXQ4Oz1H6e/2hBqhHIgKwwRjYnEFPE+LuOVQvHb6luGFJdk+rwOP mnTIkuVtFF4VFI+dEgYEb16m+Oo1SEGsBdNzK3whYYq5V01WumHnsrNTuDRGmn01 qbINmk8is/0prAWaS1HLSw7/vr4j13MyAPg9qPJfvekzSDxtaX9Q44KXihPTvkND B/sg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1700410378; x=1700496778; bh=OuwMnI0vcYFpT 9C1PoVpbOVTOl+shh447C2TOvEG3WE=; b=h70RPpcwVA3sxyYLzbfKZdE678ZNr 4xGOXWmaGLjVfuoGgOGNI1GHilnoS380OE4Ix/dh4lus38SgkVVEvayrDrKlLrRH aer42ow7gJWDef5fDK8AhQ+4fT/XvyF81HmKmXze1wzk/tWCfeaT29U3esS59ivE 6VJDu/2z+7mViCS2hZRkWGmY13jQ5JKzBzm66PKSdz5QinENK+w5E96Awfz8bOqy Z818zGBq9XaT4i+TlOBl6vQBzxl0Eyqv/d0Fre1f6bwisl1AW2AwvPlP7leVz6d3 v+79IOf2Ax7/RSCnZqffUYWHgg+V5Iq3sCss+myrKnjfpTTBK23rg68yA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeggedgkeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep vhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 19 Nov 2023 11:12:57 -0500 (EST) Date: Sun, 19 Nov 2023 16:12:55 +0000 From: void To: freebsd-arm@freebsd.org Subject: Re: pkgs for FreeBSD:14:aarch64 latest are stale compared to quarterly Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <49AAADF7-2A14-4922-AC56-B763EF0C6FB1@yahoo.com> 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=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-4.89 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.89)[-0.887]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[66.111.4.29:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4SYFzZ2Wfdz3grB X-Spamd-Bar: ---- On Sun, Nov 19, 2023 at 04:04:39PM +0000, void wrote: >so, approx 3 days for a build, I mean 4 days, sorry -- From nobody Sun Nov 19 18:21:19 2023 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 4SYJqz6wkjz5188g for ; Sun, 19 Nov 2023 18:21:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (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 4SYJqz2Jrbz4RNB for ; Sun, 19 Nov 2023 18:21:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1700418092; bh=9I3cbzdHZeq9lAtGK+pSmb/kYDybIk4m82GhzhXpUSA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=nmbRs8r2WhIXxA+6w7zFdn7Yo19s+u35oIW4j2Sqd8ZY1to+nJSJkU1y/bq09ph9eDuot6j7JUpKmaP8Mcg6NL863DvULdEl2zIzxT6KJQqfFqOu3EGVZAn2bsWe/3hA1r8QXjgrM5wRXrjy2oqhWXIXMwPy+EiKLaSnl5VcjH9Z6JIOUDs1XWOSCWvNOLaqXuqxIxz1FzNa350/XcgCliCgf3QhI1PDEaxyTvkfCNOVOU0N5dfMeI9cygYyCnEd30WKefS209Kh4IlghckavFbKeUOWYW8OkH7JNVXrwsUyyZS4gEV0bnwNi7UKLtjM9r0mOxaT52+Pnd5+kaxg0A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1700418092; bh=k0TPiaNSUYGDnsihvhUx5xHaWv23VpHuQhRqUVLBHXO=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kotbnLi+Engk6PVKXMnKmSueSC+sNUKF3OHGcW/HK7nCcKYz56fpP1YkONGr9VmexNjJAZA5vowgac9ou9Z68zWg1MfJMKII7WqADoc+W6aynpnldAyJ4fexFWHkySBLvtu6zubcyqhA/+sLICB1UkO7hieiRJazyon2hyNtu1ilcFCzCikfMEL5Nxxcq7WAW/gZAQsq1rz8aXKGt4GWWsbR0WDIZrOKenNnA2HeKKD77scmt+mvKeu01rzepphdAaScQsW3hGOh8eQALgBrJ5Ki1OSUjEbpeMwP4mb+2h6HJD7D2rO1lq1YzICao23JCewrYsd8OcowKoTMTRkqhQ== X-YMail-OSG: VU3NjXMVM1mgowBhvgjZEcROkumRij02nu0H3NeUteDzXTG1MbeQDVmZRk_bdSU 4HoIGtGV29ZHTevXkZtCxhpp0XDOU7Y6C9JA06WXZ7iiM4e.4P3DNKinExbXafPWsep_FykgxC9B U77Vk3zEPFsVvjc_u_G4GlMtI3Ix0W5Pt_9ko_WItHCJZ29IvqrEPN3rA402p1w8hkvLPWt7FGXL 5x88hXwsGC94ib_lx0ddswcJhgd2s84.F.5.wusk91bI5vD30iKs81T2rGN2PM2D5M284OOuhdOv uqNZ4iHao4vBGT1NMpkCV5BmfSYp0Y9nnc7lPb0hD9IJ36PffeInOfNs.vVGT1hyOtmuOeqs2RfB Scuu2A5pd90353tuydyZLvwG4TJk6j7bcR5sJytCyH3DxHfEk8ZkSUcWLqqQKTsYq07OwtO1rxvH rBaouBMUQtmctFa_FNTZnLErNA8RFZDKOKgnxWyzkDDAN6XbQEiZ_DMQn9JBRtNgF9r5Nn1tyKQg GyUXH71KWblDtvs7joRQTYrPiyoyhl4AWe.dVGwOTZ2WQmsljyVt7Htc5UBmMEyajMN0Gw2wsZkY duLr93j_ukfMbmI1OZCLO21BHRQtaTNlsmG7o0x8qHhVIkYWr5MMuReW6XAU1v4ZfQZEbINoXGA6 ZWhOrIxAGhKvs8GblyeZmEvZqbkUlTrjDCcJzO5g.ZK82HerRvLwoPxZmFY.cKZKLWSyCn09a0YO 3mT8QrmjY5n89RyzEtsrD2.89Rm95c8HAd1e4rf2GYb0RX7nvgawRNA3Di84fXlNF3Naau2FWoW9 nnOReggcnx2QkRitRWe6vv7_LBzL1dl2Xacy_iWjBDsRnL10gmUYbWi3HdN5nZySEg.Hl1Jz2H86 FZHBAmKC0H5hKwzQ9pU.akc1nX2JHtUJ2AQQPRlgBSGLtP6P287CEOkiKPaHTs9UfEXOlxHuRKYw BMpHM1HctfeQ6D98CH.qKPY5B.W4Z0Q_nVSWxQqIPdfA3kaqpl9Et3Gj4KEE8eaxDxp4v5i.Jg2g UghS4.I2rmRChC4_2fGLnGXQ.oxX316uo6Ej51EzzOAYfXG7L1YfOq.ZPC8f3CJUleTlmRX4AK6r dXx.4iE7lRCmTdtfVfPZgTLjK57_JhI26efkQqVeM2hfbAllRn7m9nn.xhi7vuI44LzHL3YaT966 UpgZciDcYppxKqx0uwHzdL9YaTKjFQOMuWYgtgLKvDW9sp89Oo7sJvkMX2JcSFYeFwYk01ZOV0P5 uo8PoWlBguAB7k_mpNlp2dX6Euu7LQRsUY1qHGYq17qDfei9Jkcg7XHjy3ZurxlUdUOAsn6l2ekG 81gqypaQybJEYVaAkwF_nut4L2Ak3ryXeVFGItxtBRrxtlvHay9Hgc5zHvfExcWYMqMVx4J_KxZk xIvGfx0qBNRIlvr.SQ7ysYZ150kIH9hQlQHBbeWm5UxksORH8S0DQX3caWJC_FkeZqF_byw0GH7K vFLxcqFbLGlqwKiFwc0S1xHYYRuP._eJXar7HXWWwTg_73Jogq0PeOefL88dgxRuxxgdyr3e8lCv 4a7CXbOm1PwbI.moAjkA5WJK8UgOsBi4_YMNcOtDxomcer5TNim_XliksaEBSK.NehpIdpQUYEuB So6IxlIzMFfxUCY4KagiKPDiksCv7_6DdU1hTk49.KpEuwA9MpClK263kZWjhw18OrzMymqK8sEN fqLup4MKseoV1mbkfZPBlngSlptyfZI6tSm9Cu23n7Efo9c0ARk8gH1Dq4ZSLmr_PtnoGW0aCehO ZuA10lG502I3.kFTTx4jpooaFLIKDx79oy2K8B4HUJmCT1TZX8fiSidrXIhjQ3VU5EnUxxazaBq8 oj2O7kKnX.XuX_iJjXd1Wfm5DwhtSDtsF3CHjUtEjDpN9e6mUdrrCgyBpxYcVQ_7irE5bDp9Q0TB qsujjBD5pQCBu7hl3bD.XP76AD4KUaMbx0HXOWh5pOmL.CdoqJCzfhUwTIfpnj.9Dgr_laKiNNba ETUKnG4ghsJb1J.oyRCdB7.pP793jAMoTF.eUl0_x3BDmxXBYrWyw4dfpXo.3phBhb7gYsMdPvgX MKA.zf.aBwt.e5wLXg2cXzAUtETln9xzBlGV62RUglYa7AAvkyb9RPt.wTAn7bIB.9IP1Ow2tXBI to3gxdOjm31qcPzrVGx9u0ZXbBXfikDmEhW.qjD1ZGV729SncN2fDjtgXeZNGXfQL6oMiav7dOk7 H5l28CEKOKGolnTdPJP.2g4jM5PumEGX6RNJF_AVWah3UY0aGPRv9afAmGp1DaobBGhJDatqBjGy wLA-- X-Sonic-MF: X-Sonic-ID: 68072251-f633-4382-a1b5-ead3d3c00a3c Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Nov 2023 18:21:32 +0000 Received: by hermes--production-gq1-59b5df67b6-72bc4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID dd7d1fac1788a27e084133eb579f173d; Sun, 19 Nov 2023 18:21:30 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: pkgs for FreeBSD:14:aarch64 latest are stale compared to quarterly From: Mark Millard In-Reply-To: Date: Sun, 19 Nov 2023 10:21:19 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <579E2DA6-8496-4E1C-A993-885C82C0B780@yahoo.com> References: <49AAADF7-2A14-4922-AC56-B763EF0C6FB1@yahoo.com> To: void X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4SYJqz2Jrbz4RNB On Nov 19, 2023, at 08:04, void wrote: > . . . > >> So: For (only) 140releng-arm64 the finished-dates look like: >> >> 31 Oct 2023 finish quarterly >> 02 Nov 2023 finish default (a.k.a. latest) >> 15 Nov 2023 finish quarterly >> 18 Nov 2023 finish default (a.k.a. latest) > > so, approx 3 days for a build, NO! You seems to have missed the earlier indications of which FreeBSD build servers do which builds (ampere1 vs. ampere3). So making that explicit in the summary: 31 Oct 2023 finish quarterly on server ampere1 02 Nov 2023 finish default (a.k.a. latest) on server ampere3 15 Nov 2023 finish quarterly on server ampere1 18 Nov 2023 finish default (a.k.a. latest) on server ampere3 So: over 15 days between finishing 2 140releng-arm64 builds. You also seem to havea missed all the other builds that are in the cycle each of those machines builds that contribute to the times being over 15 days between 140releng-arm64 builds. I'll not repeat all that here. > . . . > === Mark Millard marklmi at yahoo.com From nobody Sun Nov 19 18:59:40 2023 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 4SYKh50tJ8z51Bm3 for ; Sun, 19 Nov 2023 18:59:49 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SYKh40xYjz4TwN for ; Sun, 19 Nov 2023 18:59:48 +0000 (UTC) (envelope-from jfc@mit.edu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mit.edu header.s=outgoing header.b=bcK+YHc0; spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.13 as permitted sender) smtp.mailfrom=jfc@mit.edu; dmarc=pass (policy=none) header.from=mit.edu Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id 3AJIxi9S014702 for ; Sun, 19 Nov 2023 13:59:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1700420385; bh=t/B1j2UkGVbCT7pPfNr564x824mGWHhEAtscre04eq0=; h=From:Subject:Date:Message-ID:Content-Type:MIME-Version; b=bcK+YHc0H38Nt2+jmNup1c/h9OpFMH4hEj6LzmCtqavWQLpU0CsfR8ANJsqEtWCsF N1jDoFbyDjeMNuCx5TxamDhh8f8L0kOTS3pXLp1fCSgjY3+naZRO8G9qMu9xEGrQ1A OaFwdSxbVTmw1Ddw8zvvNUZsH7bvMmaa4RR19J31ODigZM2ez8b41JXTAAHByJC0Bn VJ89al/1jIh0/o6u2JNZUwzUdryhD34ZZFoghe3bOb1/iOpCwEzwm21+xfJOWP5uEN ZAspZbFMtaBOjjJ8kGCXQg+/gg1lMeplccyQBlbn9zv3h8yQGiOz6rU/izYemngaUA /2jiKx7ut1R4A== Received: from oc11expo11.exchange.mit.edu (18.9.4.16) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Sun, 19 Nov 2023 13:59:38 -0500 Received: from oc11exhyb4.exchange.mit.edu (18.9.1.100) by oc11expo11.exchange.mit.edu (18.9.4.16) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Sun, 19 Nov 2023 13:59:43 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.168) by oc11exhyb4.exchange.mit.edu (18.9.1.100) with Microsoft SMTP Server (TLS) id 15.0.1497.48 via Frontend Transport; Sun, 19 Nov 2023 13:59:43 -0500 Received: from SA3PR01MB8450.prod.exchangelabs.com (2603:10b6:806:382::17) by DM8PR01MB7173.prod.exchangelabs.com (2603:10b6:8:f::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.26; Sun, 19 Nov 2023 18:59:42 +0000 Received: from SA3PR01MB8450.prod.exchangelabs.com ([fe80::79a2:b3b5:bcdf:bdf0]) by SA3PR01MB8450.prod.exchangelabs.com ([fe80::79a2:b3b5:bcdf:bdf0%7]) with mapi id 15.20.7002.026; Sun, 19 Nov 2023 18:59:42 +0000 From: "John F Carr" To: FreeBSD ARM List Subject: Setting CPUFLAGS breaks aarch64 13.2 -> 14.0 cross compile due to invalid -mcpu= Thread-Topic: Setting CPUFLAGS breaks aarch64 13.2 -> 14.0 cross compile due to invalid -mcpu= Thread-Index: AQHaGxqMufXGvpaLwkO0BNa12fRLhg== Date: Sun, 19 Nov 2023 18:59:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SA3PR01MB8450:EE_|DM8PR01MB7173:EE_ x-ms-office365-filtering-correlation-id: 889dd5cb-237f-4eaa-c2ce-08dbe931af33 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cNYiyt5IO/joVyDMlBPuljOpby9MFCM0BToSs96HAi8bXXmWBb92gW5NdZGcZI8HSeUSAg29BAKheF7H6W3E52Nj0smXL55Tv4PyXgsCuktxkrBBQ2PVGPswNxcyfMqbPmn55DPiZlfBDZMIA7+ObkZ+u5Ho2tbPP7c5HUDX+r22bCYJBkHc+ovMS6SoI2es7ylPW77U5Rt22LpsiHJ4lPpli4ghZkRdCOSW9iDATNFRvUYWmnlNDzDPK1k4kjQj6G2arRBQHp1yORKqE4PNQ8UfFUVMOMxlIgDmjZ50BAfk+/gNcMpipxoJP1J9MUx3Gb/acx8zaYtF0x/PST0ehiu0NGhYHYq9fwZ8BPeZgiPdSOWbxKWpMb9u3Aeg0jopkpTZk2k7on978mMINF6mP2F0HCCWlCySYfofydy14fzb4pTsXEdBm8V9VFG910j6+cy4zEX2IL6H8MLmnjFMtWeR2xnSiefD77vIzmwbyJrK4cvTR/ulBdBJPWDqBpThCnKYRvSX4gMdIKk4067Yj9+g/ASYyaL1L0HZZIvEXZjjJRuyBDS/iIukx9hI8n+2syBaHUn6gXtdoRviPRpWGj5pr2wO+9KCdWquMGGJPkI6zQoc6sBb6KPFlYiBzlq/ x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR01MB8450.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230031)(136003)(39860400002)(376002)(346002)(366004)(396003)(230922051799003)(1800799012)(451199024)(186009)(64100799003)(5660300002)(2906002)(8676002)(8936002)(41300700001)(66476007)(316002)(64756008)(786003)(6916009)(66946007)(91956017)(66556008)(66446008)(76116006)(75432002)(86362001)(38070700009)(478600001)(6486002)(71200400001)(36756003)(6512007)(6506007)(2616005)(122000001)(83380400001)(33656002)(38100700002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?kQXEpv0vRLhLUS1++xB9SvCDIWKvOCTzowOatYo0Nhg9Q0wYflf74rlxTAZi?= =?us-ascii?Q?C4TSwNea14xmukT77aRwE6Yd5lnU8uYLSV4R7h5wT9Db/1CVQzDh3RJme6pD?= =?us-ascii?Q?KzWmoiN6tv7UPAXzUpn7c9X+SBLSnRqReXGFMFSIK9mDFRG9Q0Mwnv5PbcEl?= =?us-ascii?Q?TXJpGnuH+JlHCiXw4k2lSuosoB8BVvcotbPeTu5xiIraY4eEL01JNt62mW+I?= =?us-ascii?Q?yQ04E3L0sdGMpPdOld+4Tqz9GYF5L/pg6kOswz2uumSMkTeoUz6ebun63ABY?= =?us-ascii?Q?wtJ+PKFe6Km96ZfH2DYJzwYG7z4ktPuLY8uCBxy4bFNyLpSKTkhr+9Dx+x/0?= =?us-ascii?Q?8vIri61XvAaoMKCtPnmmwOta3updi2MgURSKMMKxJjI7Fk1yjeMOps8jlafZ?= =?us-ascii?Q?ag8IKchsvNuwTpiPsvHjTRmyVUjGVbtxiB9A0P5WdlOx7VxvmPvV8CVkcwlk?= =?us-ascii?Q?3goqq7UlVR1lCC7VXDxpvGIwhyDpOA6Ii8h2iyG9H2Jt0U8KIH1RKSb/AnNr?= =?us-ascii?Q?SOCvsaPoNkdels70WmYqFDFd8yd1JFNWhSsLdG9zQuK4t7iSjLo846COirq+?= =?us-ascii?Q?9vukSOL/MpoRCkgRExGncCdnwzzxDwmusHjTteYT8Sqg9JXl77uri07PF9Yk?= =?us-ascii?Q?FG8GsU+lc1nCKHEEqWBQTrlzUbxM/vgYMzm40wIC1LW+qcCKPzRndwr8olCW?= =?us-ascii?Q?HfUWqUSzEiyer6OKQ0xOQAIfAI+XNk2CkAztDca0s6D6DFKknxYxwokepTsN?= =?us-ascii?Q?SSOBQk2ehQpuoxS1tVQKzg+WIJoUwLQ5uBp0PSU0Le3Ii+EeGDSx6uXRkbt5?= =?us-ascii?Q?8rVSpsxpA9F8zTNSx0F2k70YpK4m14KJv8zh1flfJoWaivtnkG7do3EIk5n2?= =?us-ascii?Q?L8ySh4GnUQJmAAU5yv8HA1jcQ3l7poztuH4445gc2aUTY/+fBKniP7Fk5CKd?= =?us-ascii?Q?Qmu5IusrzDhDPYHJeg23bz91f4cu5qUp7UmFe9/45RmsQYEACmreWvrtCiH+?= =?us-ascii?Q?xHElV9CFjreqOWOWIRedc4uY/cK0aWBZrCdV/6zsJ7RNHjeOdcAkbpCCpJjC?= =?us-ascii?Q?qogcO4InrLtqTJXUS90HzfCPlvUS1oW2bdEsOqS03ZCA/UW4Yq+jya57BXJi?= =?us-ascii?Q?dj15xkbIYJC6qR2prOkOm/FQ/ZfK9HqcvfBiYigVdggCIPFgpFSFxD0LLdjd?= =?us-ascii?Q?fLBWJ5scyNi3TcW+yoP7f4dzs52EaOSfHe+iLv/uz3oVXVTYVd1SnOWCTin8?= =?us-ascii?Q?COJsw+G1rEbUZROlpJf7UxJNbhHkqrL7SFEL9WYZq40/lIbRf72/W03J/Jat?= =?us-ascii?Q?6WW7U3zlQC75UYQOAk67RCItGRejNTuLcd0akY1xsXv4S38mE34p9Guqv2zK?= =?us-ascii?Q?LR4ReExXqlS8qMKYq0ocn0/Y0TUGd42OWDZht4XVSRlZKzDs2/u3I+sB2b7r?= =?us-ascii?Q?eh2u5GxvOjHmXpaM3jsCvFzDZNpobIcbd/ShvRJ1EZU36n0eLF6Ygd4p9l7g?= =?us-ascii?Q?vd6dc+pe3sW/q34aYReXxlD9VDxyduqCG9qh2uzPN9R6d/pBzZQ/pgmUMk0q?= =?us-ascii?Q?FuSkttl6hSCxJIxmWjOiJYLU+s3e86dh6FWKX6ljtlJPmxEmOSwAA4ci0h8+?= =?us-ascii?Q?a2g1+TtK1PITNMPsbTXQ4V97HfwAzVmz+KvT1MTmc/eg?= Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable 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 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR01MB8450.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 889dd5cb-237f-4eaa-c2ce-08dbe931af33 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2023 18:59:40.4660 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sW2R39NifNYJKRBsfgjuifP/lUY+RkqX9upai06TnU1m1zCYXFMiVuSvFdjT2taW X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR01MB7173 X-OriginatorOrg: mit.edu X-Spamd-Result: default: False [-5.86 / 15.00]; DWL_DNSWL_LOW(-1.00)[mit.edu:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.957]; DMARC_POLICY_ALLOW(-0.50)[mit.edu,none]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCVD_IN_DNSWL_MED(-0.40)[18.9.28.13:from,18.9.3.18:received]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; R_DKIM_ALLOW(-0.20)[mit.edu:s=outgoing]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[104.47.55.168:received]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[mit.edu:+]; ARC_NA(0.00)[]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4SYKh40xYjz4TwN X-Spamd-Bar: ----- I have been building 13.2 with the following line in /etc/make.conf: CPUTYPE?=3Darmv8a+aes+crc+sha2 This matches my processor (Ampere eMAG), which llvm does not know by name. Now I want to upgrade to 14.0. I can't build from source on 13.2. Compiling 32 bit objects fails because $CPUTYPE is not valid for armv7. Setting CPUTYPE_32?=3Darmv7 does not work either. That generates an invalid compiler option -mcpu=3Darmv7. Setting CPUTYPE=3Darmv7 needs to generate only -march=3Darmv7 and not -mcpu=3Darmv7. The make infrastructure generates both. Using an empty string for CPUTYPE_32 did not work either. According to /usr/share/examples/etc/make.conf, I should be able to use CPUTYPE=3Darmv7. Is this supposed to work? Is there a /etc/make.conf variable that sets -march=3D but not -mcpu=3D? # Meta data file /usr/obj/usr/src/arm64.aarch64/libexec/rtld-elf32/crtbrand= .o.meta CMD cc -target aarch64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/arm= 64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-= common -march=3Darmv8a+aes+crc+sha2 -mcpu=3Darmv8a+aes+crc+sha2 -m32 -targ= et armv7-unknown-freebsd14.0-gnueabihf -DCOMPAT_LIBCOMPAT=3D\"32\" -DCOMP= AT_libcompat=3D\"32\" -DCOMPAT_LIB32 --sysroot=3D/usr/obj/usr/src/arm64.a= arch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/lib32 -Wall -DFREEBSD= _ELF -DIN_RTLD -ffreestanding -I/usr/src/lib/csu/common -I/usr/src/libexec/= rtld-elf/arm -I/usr/src/libexec/rtld-elf -fpic -DPIC -I/usr/src/libexec/rt= ld-elf/rtld-libc -mfpu=3Dnone -g -gz=3Dzlib -std=3Dgnu99 -Wno-format-zero-l= ength -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-paramet= er -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -= Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wchar-subs= cripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-tim= e -Wformat=3D2 -Wno-format-extra-args -Werror -Wmissing-variable-declaratio= ns -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-v= ariable -Wno-error=3Dunused-but-set-parameter -Qunused-arguments -DLOC= ORE -c /usr/src/lib/csu/common/crtbrand.S -o crtbrand.o CMD CWD /usr/obj/usr/src/arm64.aarch64/libexec/rtld-elf32 TARGET crtbrand.o OODATE /usr/src/lib/csu/common/crtbrand.S -- command output -- clang: error: unsupported argument 'armv8a+aes+crc+sha2' to option '-mcpu= =3D' clang: error: ignoring extension 'sha2' because the 'invalid' architecture = does not support it [-Werror,-Winvalid-command-line-argument] clang: error: ignoring extension 'aes' because the 'invalid' architecture d= oes not support it [-Werror,-Winvalid-command-line-argument] clang: error: unsupported argument 'armv8a+aes+crc+sha2' to option '-mcpu= =3D' clang: error: ignoring extension 'sha2' because the 'invalid' architecture = does not support it [-Werror,-Winvalid-command-line-argument] clang: error: ignoring extension 'aes' because the 'invalid' architecture d= oes not support it [-Werror,-Winvalid-command-line-argument] From nobody Sun Nov 19 20:16:30 2023 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 4SYMNv31YYz51HTd for ; Sun, 19 Nov 2023 20:16:47 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Received: from mailgate.us (mailgate.us [185.72.246.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4SYMNs5Hn7z3C4J for ; Sun, 19 Nov 2023 20:16:45 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mailgate.us header.s=mail header.b=nLOERLro; spf=pass (mx1.freebsd.org: domain of stanislav.silnicki@mailgate.us designates 185.72.246.236 as permitted sender) smtp.mailfrom=stanislav.silnicki@mailgate.us; dmarc=none Received: from localhost (api.telegram.org [192.168.2.1]) by mailgate.us (Postfix) with ESMTPSA id 12A76A682C; Sun, 19 Nov 2023 23:16:40 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailgate.us; s=mail; t=1700425002; bh=YEVClfWH4F6SqN1jdPvwivMihqXA71WOZgqvviYtwJs=; h=From:Subject:To:References:Date; b=nLOERLro8MXf6HtR2KC8BUEcc1+o+G+HfY8vm5LOlVWniHXHeFDzGZWfwFwU70o1r ic8+DX3mCAKgV9umwGr5sefLncWKhwFHOi32oE/m0a3C6CNp762gZkHoskdlOuE1iz un5IuFmnWL/PqiyjwI58NmHCq1jdEkTzgD6yUTFE= Content-Type: multipart/alternative; boundary="----sinikael-?=_1-17004249909700.06045529067781352" From: Stanislav Silnicki Subject: Re: STM32MP157 X-Type: replyAll To: John F Carr , FreeBSD ARM List User-Agent: Desktop Message-Id: References: <4d6bf0126f4fb.c24cc5f2fa47c@mailgate.us> <00cab7929791c.8af55c0bd1d5f@mailgate.us> <5d65957f4c04a4bec7ae6ef5469b149c@ohdata.se> <0dab0fc75864.77e1118ea80bb@mailgate.us> <5aa7e3eff95c.2102a80bb1a3b@mailgate.us> <0926803a4f0a.17799edcfe428@mailgate.us> <19de1a006e313.760d63ffe37aa@mailgate.us> <41EBB5DE-EB46-435A-98FC-9017A2CE3B10@mit.edu> Content-Transfer-Encoding: quoted-printable Date: Sun, 19 Nov 2023 20:16:30 +0000 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 X-Spamd-Result: default: False [-2.56 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.915]; SUBJ_ALL_CAPS(0.75)[10]; R_DKIM_ALLOW(-0.20)[mailgate.us:s=mail]; R_SPF_ALLOW(-0.20)[+ip4:185.72.246.236/32]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[mailgate.us:+]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[mailgate.us]; ASN(0.00)[asn:47447, ipnet:185.72.246.0/24, country:DE]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4SYMNs5Hn7z3C4J X-Spamd-Bar: -- ------sinikael-?=_1-17004249909700.06045529067781352 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: 7bit if you mean SRAM, stm32mp1 has some @ 0x20000000. In my current setup with ftfp boot, it is used to load SPL+uboot, then, kernel is loaded into default kernel space @ 0xc0000000, where DRAM starts. At the _start kernel's entry sp is something about 0xdd....., so it uses DRMA as well. Where can I find traces of TCM usage? John F Carr wrote: Are you using a chip where some memory can be mapped as TCM or cache? Trying to use the memory both ways could cause problems. On Nov 18, 2023, at 19:46, Stanislav Silnicki wrote: The root cause of zeroed stack in my setup with STM32MP157 seems to be in the TEX remapping registers values, calculated by pmap_set_tex(void). It can be a wrong assumption, as I'm not sure of any hardware (OTP/Security) tunings, that might be in effect.... Blindly copied values for PRRR & NMRR registers from Linux kernel (6.1.28), supplied by STM in their distribution I could avoid the trouble with zeroed stack memory. The hardcoded values are: rg ".equ\s+(PR|NM)RR" arch/arm/mm/* arch/arm/mm/proc-v7-3level.S 110:.equ PRRR, 0xeeaa4400 @ MAIR0 111:.equ NMRR, 0xff000004 @ MAIR1 arch/arm/mm/proc-v7-2level.S 137:.equ PRRR, 0xff0a81a8 138:.equ NMRR, 0x40e040e0 I (wrongly?) assume, 2level is related to the ones, calculated by pmap_set_tex. Narrowing down the inconsistency among values found in Linux kernel and calculated here, I came to the result that the type of inner cache, tuned for first value of tex_classes lut ruins memory: TEX(PRRR_MEM, NMRR_WB_WA, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - zeroes stack mem on TLB flush TEX(PRRR_MEM, NMRR_WB, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - zeroes stack mem on TLB flush TEX(PRRR_MEM, NMRR_WT, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - DOES NOT zeroes stack mem on TLB flush TEX(PRRR_MEM, NMRR_NC, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - DOES NOT zeroes stack mem on TLB flush Need further investigation.... Any clues? Stan Stanislav Silnicki wrote: STM32MP15x port current progress: ... it took some time to solder down the probe and establish conveniences with remote kernel debug... So far, I need to understand, whither or not I face an expected behavior? It looks like tlb_flush_all_local() (https://github.com/freebsd/freebsd-src/blob/525ecfdad597980ea4cd59238e24c8530dbcd31d/sys/arm/arm/pmap-v6.c#L512C14-L512C14) destroys stack memory, where return address is stored, so when stored lr is poped into pc, it is 0x0.... here is a dump of my debug session around that code: 508 cp15_prrr_set(prrr); (kgdb) i f Stack level 0, frame at 0xc0784598: pc = 0xc0557b44 in pmap_set_tex (/usr/src/sys/arm/arm/pmap-v6.c:508); saved pc = 0xc055254c called by frame at 0xc07847e0 source language c. Arglist at 0xc0784590, args: Locals at 0xc0784590, Previous frame's sp is 0xc0784598 Saved registers: r4 at 0xc0784580, r5 at 0xc0784584, r6 at 0xc0784588, r10 at 0xc078458c, r11 at 0xc0784590, lr at 0xc0784594 (kgdb) x 0xc0784594 0xc0784594: 0xc055254c (kgdb) n stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled 509 cp15_nmrr_set(nmrr); (kgdb) x 0xc0784594 0xc0784594: 0xc055254c (kgdb) n stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled 512 tlb_flush_all_local(); (kgdb) x 0xc0784594 0xc0784594: 0xc055254c (kgdb) si stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled _CP15_TLBIALL () at /usr/src/sys/arm/include/cpu-v6.h:147 147 _WF0(_CP15_TLBIALL, CP15_TLBIALL) /* Invalidate entire unified TLB */ (kgdb) si stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled tlb_flush_all_local () at /usr/src/sys/arm/include/cpu-v6.h:340 340 dsb(); (kgdb) x 0xc0784594 0xc0784594: 0x00000000 (kgdb) si stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513 513 } (kgdb) si Polling target stm32mp15x.cm4 failed, trying to reexamine Failed to read memory at 0xe000ed00 Examination failed, GDB will be halted. Polling again in 100ms Program stopped. pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513 513 } (kgdb) The address, referenced from error message (0xe000ed00) is mapped by STM's address space to "DDR extension (CA7 only) or Debug" with debug assigned to Cortex-M4 coprocessor. I'm not sure, that it is an unexpected behav. (it is my first attempt to port to armv7), so need an advice. Any? Stan Stanislav Silnicki wrote: my current progress of STM32MP1xx port attempt: Basically, both options to boot ubldr and then kernel in SPL & TF-A modes of u-boot are supported. Initially, when I stated from TF-A options (security supervision from arm's trusted firmware os) I stuck with this line: https://github.com/freebsd/freebsd-src/blob/501bdf3001190686bf55d9d333cb533858c2cf2f/sys/arm/arm/locore-v6.S#L371 control does not seem to reach beyond that point. I tried to enable the led with this assembly, which works anywhere else: /* prepare to use LED @ GPIOA 13*/ ldr r0, =0x50002014 ldr r1, =0xFFFFDFFF ldr r2, [r0] and r2, r1, r2 /* Enable caches. */ mrc CP15_SCTLR(r7) orr r7, #CPU_CONTROL_DC_ENABLE orr r7, #CPU_CONTROL_IC_ENABLE orr r7, #CPU_CONTROL_BPRD_ENABLE mcr CP15_SCTLR(r7) DSB /* turn on GPIO LED */ str r2, [r0] Control passes if I disable data cache ORing instruction, but then hangs on setting of new TTB couple lines below... I thought it was due to security access control from TF-A, but it behaves the same w/o. Any clues or expertise from other platforms are highly appreciated. Stan Stanislav Silnicki wrote: Hello, I need an advice on the intial addresses layout when booting the kernel. As I understand, ubldr is the proper way to boot the kernel. What is the correct address to load it, given that I wand to keep default KERNVIRTADDR (=0xc0000000) intact? The u-boot loads ubldr this way in my current setup: // FreeBSD version of environment env_set("baudrate", "115200"); env_set("console", "ttyS0,115200"); env_set("stderr", "serial"); env_set("stdin", "serial"); env_set("stdout", "serial"); env_set("autostart", "yes"); env_set("loaderdev", "mmc 1"); // fbsd's ubldr treats our second mmc at index 1 env_set("bootcmd", "fatload mmc 2 0xc0000000 ubldr && bootelf"); then ubldr leads the kernel from mmc and passes it the control: Loading kernel... /boot/kernel/kernel text=0x1b4 text=0x5b8530 text=0x17d91c data=0xa4a60 data=0x0+0x20c000 0x4+0x88810+0x4+0xe9d98| Loading configured modules... can't find '/boot/entropy' can't find '/etc/hostid' Using DTB compiled into kernel. Kernel entry at 0xc0400200... Kernel args: (null) Then I could correctly pass the init of MMU and get into translated mode only with setting KERNVIRTADDR = 0xc4000000. It looks like kernel and loader clash somehow. So, just need to understand what is best option to load ubldr to? Will it affect further routines? Stan Stanislav Silnicki wrote: OK, I got the idea! As I realize, there is a minor bug in dtc, which affects compilation of stm's originated DTBs. I think it is best to make a PR into https://github.com/davidchisnall/dtc, which I'm discussing with repo owner already. Please tell me, that I need to post PR into FBSD source tree if it is a shorter way for my fix. My current setup is based upon QBASE1 from Karo-Electronics, but there is no goal to support/debug all peripherals, only a subset, including USB, I2C, SDMMC, DSI (and GPU, if lucky). https://www.karo-electronics.com/fileadmin/download/Datasheets/QSMP-QSBASE1-Evalkit.pdf The vendor (Karo) supports only their Yocto based Linux distro. I spent some time to prepare TF-A & Uboot, capable with booting from SD card (that is more robust approach, as I think). STM does not promote/support non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it is pretty cumbersome path, I had to pass. I think, it will be easier for me to prepare some sort of README to support customization of uboot for STM's port and dig it somewhere in SRC rather than ; ; ; ; ;try to post PR's in those repos... Not sure, anyway. So far I'm struggling with uart and early_printf... I'm mixing this activity with my current occupation, so I don't expect rapid progress. Thank you for clarifications! I'll try to do my best! Stan Oskar Holmlund wrote: Hi Stanislav, Please resend your message and CC the arm mailing list. It might be interesting for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think you stopped working on the STM32 port. You should always keep one terminal up n running % man 9 style :) https://wiki.freebsd.org/Phabricator will give you some information. Its good if you get to know the people active in the ARM area, just keep an eye on the mailinglist and you will notice some names. If you have the opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even more people. Join the IRC, for example on efnet #bsdmips is a good channel for ARM stuff. Start with small changes and you will get feedback. From there the experience will grow and you will get into it all. Correct, the device-tree import is from the Linux kernel and there is no prior work for the STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD either. Probably because the STM32MP15 is the first(?) application SoC from ST? 1) hum? Do you need that for the reviews? It should be in SRC 2) Target branch is probably main. 3) It depends, if your custom board is opensource and availble around the globe through mouser/farnell/.. I dont see any problem. Otherwise pick the board from ST that you used as a reference when you developed the custom board. For example in my day job we have a custom board built around the octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black wifi. So the code thats goes into the FreeBSD project are all tested on the beaglebone boards. The stuff we need for our custom board like the device tree is keept as local patches in our inhouse build process. //Oskar 2023-10-28 14:25 skrev Stanislav Silnicki: Hi Oskar! > can you point me some guidelines to help myself to fit development process? I'm sure, there is mature dev. culture around FBSD and I'd be happy to make my contribution coherently from the beginning. > So far I'm done with setup of my account at reviews (keys, 2FA, etc.) > As I understand, there is no considerable progress with STM32, although I have noticed, there are some DTS imported into the project. > > Indeed, several major questions: 1. repo url? 2. tagret branch for patches for stm32 hw? 3. is it possible to target custom board from our project, or I have to ensure support for all dev. boards, provided by STM? > Thank you,Stan > Oskar Holmlund wrote: >> 2023-10-27 22:33 skrev Stanislav Silnicki: quote class="gmail_quote" type="cite" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> >>> Hello! I'm porting onto the subject hardware. So far the progress is modest, while the system boots (without console although...) One of major issues is hardcoded value inside locore-v6.S. Here is my relevant post: >> > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438 [1] What is the best way to proceed? Patch, vendor kernel build, something else? Stan > Links: ------ >> [1] > > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438 >> Hi Stan, >> Upload your patch to reviews.freebsd.org >> Love to see your other patches for the STM32MP15x. kquote> >> //Oskar < < >
if you mean SRAM, stm32mp1 has some @ 0x20000000. In my current setup with  ftfp boot, it is used to load SPL+uboot, then, kernel is loaded into default kernel space @ 0xc0000000, where DRAM starts. At the _start kernel's entry sp is something about 0xdd....., so it uses DRMA as well. Where can I find traces of TCM usage?

John F Carr wrote:


Are you using a chip where some memory can be mapped as TCM or cache?
Trying to use the memory both ways could cause problems.


quote class="gmail_quote" type="cite" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Nov 18, 2023, at 19:46, Stanislav Silnicki <stanislav.silnicki@mailgate.us> wrote:
The root cause of zeroed stack in my setup with STM32MP157 seems to be in the TEX remapping registers values, calculated by  pmap_set_tex(void). It can be a wrong assumption, as I'm not sure of any hardware (OTP/Security) tunings, that might be in effect....
Blindly copied values for PRRR & NMRR registers from Linux kernel (6.1.28), supplied by STM in their distribution I could avoid the trouble with zeroed stack memory. The hardcoded values are:
rg ".equ\s+(PR|NM)RR" arch/arm/mm/*
arch/arm/mm/proc-v7-3level.S
110:.equ PRRR, 0xeeaa4400 @ MAIR0
111:.equ NMRR, 0xff000004 @ MAIR1
arch/arm/mm/proc-v7-2level.S
137:.equ PRRR, 0xff0a81a8
138:.equ NMRR, 0x40e040e0
I (wrongly?) assume, 2level is related to the ones, calculated by pmap_set_tex.
Narrowing down the inconsistency among values found in Linux kernel and calculated here, I came to the result that the type of inner cache, tuned for first value of tex_classes lut ruins memory:
TEX(PRRR_MEM, NMRR_WB_WA,    NMRR_WB_WA, 0),  /* 0 - ATTR_WB_WA */ - zeroes stack mem on TLB flush
TEX(PRRR_MEM, NMRR_WB,    NMRR_WB_WA, 0),  /* 0 - ATTR_WB_WA */ - zeroes stack mem on TLB flush
TEX(PRRR_MEM, NMRR_WT,    NMRR_WB_WA, 0),  /* 0 - ATTR_WB_WA */ - DOES NOT zeroes stack mem on TLB flush
TEX(PRRR_MEM, NMRR_NC,    NMRR_WB_WA, 0),  /* 0 - ATTR_WB_WA */ - DOES NOT zeroes stack mem on TLB flush
Need further investigation....
Any clues?
Stan
Stanislav Silnicki wrote:

STM32MP15x port current progress:
... it took some time to solder down the probe and establish conveniences with remote kernel debug...
So far, I need to understand, whither or not I face an expected behavior?
It looks like tlb_flush_all_local() (https://github.com/freebsd/freebsd-src/blob/525ecfdad597980ea4cd59238e24c8530dbcd31d/sys/arm/arm/pmap-v6.c#L512C14-L512C14)
destroys stack memory, where return address is stored, so when stored lr is poped into pc, it is 0x0....
here is a dump of my debug session around that code:
508 cp15_prrr_set(prrr);
(kgdb) i f
Stack level 0, frame at 0xc0784598:
pc = 0xc0557b44 in pmap_set_tex (/usr/src/sys/arm/arm/pmap-v6.c:508); saved pc = 0xc055254c
called by frame at 0xc07847e0
source language c.
Arglist at 0xc0784590, args:
Locals at 0xc0784590, Previous frame's sp is 0xc0784598
Saved registers:
r4 at 0xc0784580, r5 at 0xc0784584, r6 at 0xc0784588, r10 at 0xc078458c, r11 at 0xc0784590, lr at 0xc0784594
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) n
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
509 cp15_nmrr_set(nmrr);
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) n
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
512 tlb_flush_all_local();
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
_CP15_TLBIALL () at /usr/src/sys/arm/include/cpu-v6.h:147
147 _WF0(_CP15_TLBIALL, CP15_TLBIALL) /* Invalidate entire unified TLB */
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
tlb_flush_all_local () at /usr/src/sys/arm/include/cpu-v6.h:340
340 dsb();
(kgdb) x 0xc0784594
0xc0784594: 0x00000000
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513
513 }
(kgdb) si
Polling target stm32mp15x.cm4 failed, trying to reexamine
Failed to read memory at 0xe000ed00
Examination failed, GDB will be halted. Polling again in 100ms
Program stopped.
pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513
513 }
(kgdb)
The address, referenced from error message (0xe000ed00) is mapped by STM's address space to "DDR extension (CA7 only) or Debug" with debug assigned to Cortex-M4 coprocessor.
I'm not sure, that it is an unexpected behav. (it is my first attempt to port to armv7), so need an advice.
Any?
Stan
Stanislav Silnicki wrote:

my current progress of STM32MP1xx port attempt:
Basically, both options to boot ubldr and then kernel in SPL & TF-A modes of u-boot are supported.
Initially, when I stated from TF-A options (security supervision from arm's trusted firmware os) I stuck with
this line: https://github.com/freebsd/freebsd-src/blob/501bdf3001190686bf55d9d333cb533858c2cf2f/sys/arm/arm/locore-v6.S#L371
control does not seem to reach beyond that point. I tried to enable the led with this assembly, which works anywhere else:
  /* prepare to use LED @ GPIOA 13*/
  ldr r0, =0x50002014
  ldr r1, =0xFFFFDFFF
  ldr r2, [r0]
  and r2, r1, r2
/* Enable caches. */
mrc CP15_SCTLR(r7)
orr r7, #CPU_CONTROL_DC_ENABLE
orr r7, #CPU_CONTROL_IC_ENABLE
orr r7, #CPU_CONTROL_BPRD_ENABLE
mcr CP15_SCTLR(r7)
DSB
  /* turn on GPIO LED */
  str r2, [r0]
Control passes if I disable data cache ORing instruction, but then hangs on setting of new TTB couple lines below...
I thought it was due to security access control from TF-A, but it behaves the same w/o.
Any clues or expertise from other platforms are highly appreciated.
Stan
Stanislav Silnicki wrote:

Hello, I need an advice on the intial addresses layout when booting the kernel.
As I understand, ubldr is the proper way to boot the kernel.
What is the correct address to load it, given that I wand to keep default KERNVIRTADDR (=0xc0000000) intact?
The u-boot loads ubldr this way in my current setup:
// FreeBSD version of environment
env_set("baudrate", "115200");
env_set("console", "ttyS0,115200");
env_set("stderr", "serial");
env_set("stdin", "serial");
env_set("stdout", "serial");
env_set("autostart", "yes");
env_set("loaderdev", "mmc 1"); // fbsd's ubldr treats our second mmc at index 1
env_set("bootcmd", "fatload mmc 2 0xc0000000 ubldr && bootelf");
then ubldr leads the kernel from mmc and passes it the control:
Loading kernel...
/boot/kernel/kernel text=0x1b4 text=0x5b8530 text=0x17d91c data=0xa4a60 data=0x0+0x20c000 0x4+0x88810+0x4+0xe9d98|
Loading configured modules...
can't find '/boot/entropy'
can't find '/etc/hostid'
Using DTB compiled into kernel.
Kernel entry at 0xc0400200...
Kernel args: (null)
Then I could correctly pass the init of MMU and get into translated mode only with setting KERNVIRTADDR = 0xc4000000. It looks like kernel and loader clash somehow.
So, just need to understand what is best option to load ubldr to? Will it affect further routines?
Stan
Stanislav Silnicki wrote:

OK, I got the idea!
As I realize, there is a minor bug in dtc, which affects compilation of stm's originated DTBs. I think it is best to make a PR into https://github.com/davidchisnall/dtc, which I'm discussing with repo owner already. Please tell me, that I need to post PR into FBSD source tree if it is a shorter way for my fix.
My current setup is based upon QBASE1 from Karo-Electronics, but there is no goal to support/debug all peripherals, only a subset, including USB, I2C, SDMMC, DSI (and GPU, if lucky).
https://www.karo-electronics.com/fileadmin/download/Datasheets/QSMP-QSBASE1-Evalkit.pdf
The vendor (Karo) supports only their Yocto based Linux distro. I spent some time to prepare TF-A & Uboot, capable with booting from SD card (that is more robust approach, as I think). STM does not promote/support non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it is pretty cumbersome path, I had to pass. I think, it will be easier for me to prepare some sort of README to support customization of uboot for STM's port and dig it somewhere in SRC rather than  ; ; ; ; ;try to post PR's in those repos... Not sure, anyway.
So far I'm struggling with uart and early_printf...
I'm mixing this activity with my current occupation, so I don't expect rapid progress.
Thank you for clarifications! I'll try to do my best!
Stan
Oskar Holmlund wrote:

Hi Stanislav,
Please resend your message and CC the arm mailing list. It might be interesting for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think you stopped working on the STM32 port.
You should always keep one terminal up n running % man 9 style :)
https://wiki.freebsd.org/Phabricator will give you some information.
Its good if you get to know the people active in the ARM area, just keep an eye on the mailinglist and you will notice some names. If you have the opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even more people.
Join the IRC, for example on efnet #bsdmips is a good channel for ARM stuff.
Start with small changes and you will get feedback. From there the experience will grow and you will get into it all.
Correct, the device-tree import is from the Linux kernel and there is no prior work for the STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD either.
Probably because the STM32MP15 is the first(?) application SoC from ST?
1) hum? Do you need that for the reviews? It should be in SRC
2) Target branch is probably main.
3) It depends, if your custom board is opensource and availble around the globe through mouser/farnell/.. I dont see any problem. Otherwise pick the board from ST that you used as a reference when you developed the custom board.
For example in my day job we have a custom board built around the octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black wifi. So the code thats goes into the FreeBSD project are all tested on the beaglebone boards. The stuff we need for our custom board like the device tree is keept as local patches in our inhouse build process.
//Oskar
2023-10-28 14:25 skrev Stanislav Silnicki:

Hi Oskar!
> can you point me some guidelines to help myself to fit development
process? I'm sure, there is mature dev. culture around FBSD and I'd be
happy to make my contribution coherently from the beginning.
> So far I'm done with setup of my account at reviews (keys, 2FA, etc.)
> As I understand, there is no considerable progress with STM32,
although I have noticed, there are some DTS imported into the project.
> > Indeed, several major questions:
1. repo url?
2. tagret branch for patches for stm32 hw?
3. is it possible to target custom board from our project, or I have
to ensure support for all dev. boards, provided by STM?
> Thank you,Stan
> Oskar Holmlund wrote:
>> 2023-10-27 22:33 skrev Stanislav Silnicki:
quote class="gmail_quote" type="cite" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>>> Hello!


I'm porting onto the subject hardware. So far the progress is
modest,
while the system boots (without console although...)
One of major issues is hardcoded value inside locore-v6.S. Here
is my
relevant post:
>> > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
[1]
What is the best way to proceed? Patch, vendor kernel build,
something
else?
Stan

> Links:

------
>> [1] >
> https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
>> Hi Stan,
>> Upload your patch to reviews.freebsd.org
>> Love to see your other patches for the STM32MP15x.
kquote>


>> //Oskar







<

<
>

------sinikael-?=_1-17004249909700.06045529067781352-- From nobody Sun Nov 19 21:01:04 2023 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 4SYNN10wlkz51KXf for ; Sun, 19 Nov 2023 21:01:05 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SYNN04sb2z3JyC for ; Sun, 19 Nov 2023 21:01:04 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700427664; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=F0T+QNHnXbqW9hwmioO830RMdrlEhSgZPXvueo9Nr6w=; b=gcOwLDbTXI8IdenS3gpDlZhWE0RiqMAST7y3Rd1cAet4cVJzZ6zeZ3S8feyZ6/NbYEkl+G vWCZMXj7XwGJMmZEgmi9bF3EZX6NpnynTtgMxGyIxWbWNF7WhOeDgEBkocfk4OBzEcz4nA h61Tatyxv5qlPEwTtkDWObZHdLuY4iZGB4J48IAOJxJWMNdSLbz2l7TxQrmqtUu8cb9zcU +LCm1KMA0hhr/mwfC3vtdjJyDHNQLk71qo3tXlPBMuk/z9YLw4EnuWnauDUGtBtrvP9KbY 9VxekqrqpjZr2norsC35moFTYd31wAGLcgqTft0NixxpX9TfNdyCe7D1HrpwGw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1700427664; a=rsa-sha256; cv=none; b=AG5SXellJZ93AubTijYRVbRTWfaKMIJh5TwnZpBZrJrhZaAydYuXEBXAYlTyDzECjvIwZB q38/dbvYilwZm8nPSFFUhEQsT6wBpnRg0Q0jHfxPa8W8FPnObIu/y6xZwVG+MA0CU9BQnP GAycdSCrocZPaMIBcYx70SNLNo7wSHLMCGznwVP9uwZX/LHfxdyzUsWmDKNR0PnQDebHvM kBVf0IKh791O3T3i1iUOJFQ+eAV7wQ07pRA8DEDE5vqVCc0pM3eMmqPk+eYUNZddbsPktI wsWYSmjDHUOSVn24X6JbReTD40NrrIO3xzb9br3rLRcOtSgqOB8LYQX/7rIXXg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4SYNN03cCcz9Jr for ; Sun, 19 Nov 2023 21:01:04 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3AJL14Zx031310 for ; Sun, 19 Nov 2023 21:01:04 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3AJL145O031309 for freebsd-arm@FreeBSD.org; Sun, 19 Nov 2023 21:01:04 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202311192101.3AJL145O031309@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 19 Nov 2023 21:01:04 +0000 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: multipart/alternative; boundary="17004276644.5Cbd7E9E.27219" Content-Transfer-Encoding: 7bit --17004276644.5Cbd7E9E.27219 Date: Sun, 19 Nov 2023 21:01:04 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat 2 problems total for which you should take action. --17004276644.5Cbd7E9E.27219 Date: Sun, 19 Nov 2023 21:01:04 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off 
Open        |    257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat

2 problems total for which you should take action.
--17004276644.5Cbd7E9E.27219-- From nobody Sun Nov 19 21:51:27 2023 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 4SYPVM5Vtsz51P1v for ; Sun, 19 Nov 2023 21:51:39 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Received: from mailgate.us (mailgate.us [185.72.246.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4SYPVL2c4sz3R2C for ; Sun, 19 Nov 2023 21:51:38 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mailgate.us header.s=mail header.b=Td6TQ0Pk; spf=pass (mx1.freebsd.org: domain of stanislav.silnicki@mailgate.us designates 185.72.246.236 as permitted sender) smtp.mailfrom=stanislav.silnicki@mailgate.us; dmarc=none Received: from localhost (api.telegram.org [192.168.2.1]) by mailgate.us (Postfix) with ESMTPSA id B9F5AA6A4A for ; Mon, 20 Nov 2023 00:51:33 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailgate.us; s=mail; t=1700430696; bh=M05v7wW9ToEEz+nEJ9QrN3Rqc9YBy5otRd6z14NODm8=; h=From:Subject:To:References:Date; b=Td6TQ0Pkhi6OjS9lhB2UiMvOIVIjhhx1XmItj6WaJzqnMFqNUo+84LfwgXHeLOYY7 7m85aYLMpXMb3mPdJkXqsY8cz+nMd8vjQD6D/eA2dwPspedn2XsRwKAvrRSpixJnNU ZB94jpc7I7FonPzjseGl3Z3DqRpADTvNIHgocqhE= Content-Type: multipart/alternative; boundary="----sinikael-?=_1-17004306876680.537296210982912" From: Stanislav Silnicki Subject: Re: STM32MP157 X-Type: replyAll To: FreeBSD ARM List User-Agent: Desktop Message-Id: <689d44174e0f9.1733c7a78ebda@mailgate.us> References: <4d6bf0126f4fb.c24cc5f2fa47c@mailgate.us> <00cab7929791c.8af55c0bd1d5f@mailgate.us> <5d65957f4c04a4bec7ae6ef5469b149c@ohdata.se> <0dab0fc75864.77e1118ea80bb@mailgate.us> <5aa7e3eff95c.2102a80bb1a3b@mailgate.us> <0926803a4f0a.17799edcfe428@mailgate.us> <19de1a006e313.760d63ffe37aa@mailgate.us> <41EBB5DE-EB46-435A-98FC-9017A2CE3B10@mit.edu> Content-Transfer-Encoding: quoted-printable Date: Sun, 19 Nov 2023 21:51:27 +0000 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 X-Spamd-Result: default: False [-2.64 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJ_ALL_CAPS(0.75)[10]; R_SPF_ALLOW(-0.20)[+ip4:185.72.246.236/32]; R_DKIM_ALLOW(-0.20)[mailgate.us:s=mail]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_NO_TLS_LAST(0.10)[]; XM_UA_NO_VERSION(0.01)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[mailgate.us:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:47447, ipnet:185.72.246.0/24, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[mailgate.us]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4SYPVL2c4sz3R2C X-Spamd-Bar: -- ------sinikael-?=_1-17004306876680.537296210982912 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: 7bit Reading TCMTR shows 0x0, so is looks like TCM is not implemented in my case... Stanislav Silnicki wrote: if you mean SRAM, stm32mp1 has some @ 0x20000000. In my current setup with ftfp boot, it is used to load SPL+uboot, then, kernel is loaded into default kernel space @ 0xc0000000, where DRAM starts. At the _start kernel's entry sp is something about 0xdd....., so it uses DRMA as well. Where can I find traces of TCM usage? John F Carr wrote: Are you using a chip where some memory can be mapped as TCM or cache? Trying to use the memory both ways could cause problems. On Nov 18, 2023, at 19:46, Stanislav Silnicki wrote: The root cause of zeroed stack in my setup with STM32MP157 seems to be in the TEX remapping registers values, calculated by pmap_set_tex(void). It can be a wrong assumption, as I'm not sure of any hardware (OTP/Security) tunings, that might be in effect.... Blindly copied values for PRRR & NMRR registers from Linux kernel (6.1.28), supplied by STM in their distribution I could avoid the trouble with zeroed stack memory. The hardcoded values are: rg ".equ\s+(PR|NM)RR" arch/arm/mm/* arch/arm/mm/proc-v7-3level.S 110:.equ PRRR, 0xeeaa4400 @ MAIR0 111:.equ NMRR, 0xff000004 @ MAIR1 arch/arm/mm/proc-v7-2level.S 137:.equ PRRR, 0xff0a81a8 138:.equ NMRR, 0x40e040e0 I (wrongly?) assume, 2level is related to the ones, calculated by pmap_set_tex. Narrowing down the inconsistency among values found in Linux kernel and calculated here, I came to the result that the type of inner cache, tuned for first value of tex_classes lut ruins memory: TEX(PRRR_MEM, NMRR_WB_WA, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - zeroes stack mem on TLB flush TEX(PRRR_MEM, NMRR_WB, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - zeroes stack mem on TLB flush TEX(PRRR_MEM, NMRR_WT, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - DOES NOT zeroes stack mem on TLB flush TEX(PRRR_MEM, NMRR_NC, NMRR_WB_WA, 0), /* 0 - ATTR_WB_WA */ - DOES NOT zeroes stack mem on TLB flush Need further investigation.... Any clues? Stan Stanislav Silnicki wrote: STM32MP15x port current progress: ... it took some time to solder down the probe and establish conveniences with remote kernel debug... So far, I need to understand, whither or not I face an expected behavior? It looks like tlb_flush_all_local() (https://github.com/freebsd/freebsd-src/blob/525ecfdad597980ea4cd59238e24c8530dbcd31d/sys/arm/arm/pmap-v6.c#L512C14-L512C14) destroys stack memory, where return address is stored, so when stored lr is poped into pc, it is 0x0.... here is a dump of my debug session around that code: 508 cp15_prrr_set(prrr); (kgdb) i f Stack level 0, frame at 0xc0784598: pc = 0xc0557b44 in pmap_set_tex (/usr/src/sys/arm/arm/pmap-v6.c:508); saved pc = 0xc055254c called by frame at 0xc07847e0 source language c. Arglist at 0xc0784590, args: Locals at 0xc0784590, Previous frame's sp is 0xc0784598 Saved registers: r4 at 0xc0784580, r5 at 0xc0784584, r6 at 0xc0784588, r10 at 0xc078458c, r11 at 0xc0784590, lr at 0xc0784594 (kgdb) x 0xc0784594 0xc0784594: 0xc055254c (kgdb) n stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled 509 cp15_nmrr_set(nmrr); (kgdb) x 0xc0784594 0xc0784594: 0xc055254c (kgdb) n stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled 512 tlb_flush_all_local(); (kgdb) x 0xc0784594 0xc0784594: 0xc055254c (kgdb) si stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled _CP15_TLBIALL () at /usr/src/sys/arm/include/cpu-v6.h:147 147 _WF0(_CP15_TLBIALL, CP15_TLBIALL) /* Invalidate entire unified TLB */ (kgdb) si stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled tlb_flush_all_local () at /usr/src/sys/arm/include/cpu-v6.h:340 340 dsb(); (kgdb) x 0xc0784594 0xc0784594: 0x00000000 (kgdb) si stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513 513 } (kgdb) si Polling target stm32mp15x.cm4 failed, trying to reexamine Failed to read memory at 0xe000ed00 Examination failed, GDB will be halted. Polling again in 100ms Program stopped. pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513 513 } (kgdb) The address, referenced from error message (0xe000ed00) is mapped by STM's address space to "DDR extension (CA7 only) or Debug" with debug assigned to Cortex-M4 coprocessor. I'm not sure, that it is an unexpected behav. (it is my first attempt to port to armv7), so need an advice. Any? Stan Stanislav Silnicki wrote: my current progress of STM32MP1xx port attempt: Basically, both options to boot ubldr and then kernel in SPL & TF-A modes of u-boot are supported. Initially, when I stated from TF-A options (security supervision from arm's trusted firmware os) I stuck with this line: https://github.com/freebsd/freebsd-src/blob/501bdf3001190686bf55d9d333cb533858c2cf2f/sys/arm/arm/locore-v6.S#L371 control does not seem to reach beyond that point. I tried to enable the led with this assembly, which works anywhere else: /* prepare to use LED @ GPIOA 13*/ ldr r0, =0x50002014 ldr r1, =0xFFFFDFFF ldr r2, [r0] and r2, r1, r2 /* Enable caches. */ mrc CP15_SCTLR(r7) orr r7, #CPU_CONTROL_DC_ENABLE orr r7, #CPU_CONTROL_IC_ENABLE orr r7, #CPU_CONTROL_BPRD_ENABLE mcr CP15_SCTLR(r7) DSB /* turn on GPIO LED */ str r2, [r0] Control passes if I disable data cache ORing instruction, but then hangs on setting of new TTB couple lines below... I thought it was due to security access control from TF-A, but it behaves the same w/o. Any clues or expertise from other platforms are highly appreciated. Stan Stanislav Silnicki wrote: Hello, I need an advice on the intial addresses layout when booting the kernel. As I understand, ubldr is the proper way to boot the kernel. What is the correct address to load it, given that I wand to keep default KERNVIRTADDR (=0xc0000000) intact? The u-boot loads ubldr this way in my current setup: // FreeBSD version of environment env_set("baudrate", "115200"); env_set("console", "ttyS0,115200"); env_set("stderr", "serial"); env_set("stdin", "serial"); env_set("stdout", "serial"); env_set("autostart", "yes"); env_set("loaderdev", "mmc 1"); // fbsd's ubldr treats our second mmc at index 1 env_set("bootcmd", "fatload mmc 2 0xc0000000 ubldr && bootelf"); then ubldr leads the kernel from mmc and passes it the control: Loading kernel... /boot/kernel/kernel text=0x1b4 text=0x5b8530 text=0x17d91c data=0xa4a60 data=0x0+0x20c000 0x4+0x88810+0x4+0xe9d98| Loading configured modules... can't find '/boot/entropy' can't find '/etc/hostid' Using DTB compiled into kernel. Kernel entry at 0xc0400200... Kernel args: (null) Then I could correctly pass the init of MMU and get into translated mode only with setting KERNVIRTADDR = 0xc4000000. It looks like kernel and loader clash somehow. So, just need to understand what is best option to load ubldr to? Will it affect further routines? Stan Stanislav Silnicki wrote: OK, I got the idea! As I realize, there is a minor bug in dtc, which affects compilation of stm's originated DTBs. I think it is best to make a PR into https://github.com/davidchisnall/dtc, which I'm discussing with repo owner already. Please tell me, that I need to post PR into FBSD source tree if it is a shorter way for my fix. My current setup is based upon QBASE1 from Karo-Electronics, but there is no goal to support/debug all peripherals, only a subset, including USB, I2C, SDMMC, DSI (and GPU, if lucky). https://www.karo-electronics.com/fileadmin/download/Datasheets/QSMP-QSBASE1-Evalkit.pdf The vendor (Karo) supports only their Yocto based Linux distro. I spent some time to prepare TF-A & Uboot, capable with booting from SD card (that is more robust approach, as I think). STM does not promote/support non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it is pretty cumbersome path, I had to pass. I think, it will be easier for me to prepare some sort of README to support customization of uboot for STM's port and dig it somewhere in SRC rather than ; ; ; ; ;try to post PR's in those repos... Not sure, anyway. So far I'm struggling with uart and early_printf... I'm mixing this activity with my current occupation, so I don't expect rapid progress. Thank you for clarifications! I'll try to do my best! Stan Oskar Holmlund wrote: Hi Stanislav, Please resend your message and CC the arm mailing list. It might be interesting for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think you stopped working on the STM32 port. You should always keep one terminal up n running % man 9 style :) https://wiki.freebsd.org/Phabricator will give you some information. Its good if you get to know the people active in the ARM area, just keep an eye on the mailinglist and you will notice some names. If you have the opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even more people. Join the IRC, for example on efnet #bsdmips is a good channel for ARM stuff. Start with small changes and you will get feedback. From there the experience will grow and you will get into it all. Correct, the device-tree import is from the Linux kernel and there is no prior work for the STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD either. Probably because the STM32MP15 is the first(?) application SoC from ST? 1) hum? Do you need that for the reviews? It should be in SRC 2) Target branch is probably main. 3) It depends, if your custom board is opensource and availble around the globe through mouser/farnell/.. I dont see any problem. Otherwise pick the board from ST that you used as a reference when you developed the custom board. For example in my day job we have a custom board built around the octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black wifi. So the code thats goes into the FreeBSD project are all tested on the beaglebone boards. The stuff we need for our custom board like the device tree is keept as local patches in our inhouse build process. //Oskar 2023-10-28 14:25 skrev Stanislav Silnicki: Hi Oskar! > can you point me some guidelines to help myself to fit development process? I'm sure, there is mature dev. culture around FBSD and I'd be happy to make my contribution coherently from the beginning. > So far I'm done with setup of my account at reviews (keys, 2FA, etc.) > As I understand, there is no considerable progress with STM32, although I have noticed, there are some DTS imported into the project. > > Indeed, several major questions: 1. repo url? 2. tagret branch for patches for stm32 hw? 3. is it possible to target custom board from our project, or I have to ensure support for all dev. boards, provided by STM? > Thank you,Stan > Oskar Holmlund wrote: >> 2023-10-27 22:33 skrev Stanislav Silnicki: quote class="gmail_quote" type="cite" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> >>> Hello! I'm porting onto the subject hardware. So far the progress is modest, while the system boots (without console although...) One of major issues is hardcoded value inside locore-v6.S. Here is my relevant post: >> > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438 [1] What is the best way to proceed? Patch, vendor kernel build, something else? Stan > Links: ------ >> [1] > > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438 >> Hi Stan, >> Upload your patch to reviews.freebsd.org >> Love to see your other patches for the STM32MP15x. kquote> >> //Oskar < < >
Reading TCMTR shows 0x0, so is looks like TCM is not implemented in my case...

Stanislav Silnicki wrote:


if you mean SRAM, stm32mp1 has some @ 0x20000000. In my current setup with  ftfp boot, it is used to load SPL+uboot, then, kernel is loaded into default kernel space @ 0xc0000000, where DRAM starts. At the _start kernel's entry sp is something about 0xdd....., so it uses DRMA as well. Where can I find traces of TCM usage?

John F Carr wrote:


Are you using a chip where some memory can be mapped as TCM or cache?
Trying to use the memory both ways could cause problems.


quote class="gmail_quote" type="cite" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Nov 18, 2023, at 19:46, Stanislav Silnicki <stanislav.silnicki@mailgate.us> wrote:
The root cause of zeroed stack in my setup with STM32MP157 seems to be in the TEX remapping registers values, calculated by  pmap_set_tex(void). It can be a wrong assumption, as I'm not sure of any hardware (OTP/Security) tunings, that might be in effect....
Blindly copied values for PRRR & NMRR registers from Linux kernel (6.1.28), supplied by STM in their distribution I could avoid the trouble with zeroed stack memory. The hardcoded values are:
rg ".equ\s+(PR|NM)RR" arch/arm/mm/*
arch/arm/mm/proc-v7-3level.S
110:.equ PRRR, 0xeeaa4400 @ MAIR0
111:.equ NMRR, 0xff000004 @ MAIR1
arch/arm/mm/proc-v7-2level.S
137:.equ PRRR, 0xff0a81a8
138:.equ NMRR, 0x40e040e0
I (wrongly?) assume, 2level is related to the ones, calculated by pmap_set_tex.
Narrowing down the inconsistency among values found in Linux kernel and calculated here, I came to the result that the type of inner cache, tuned for first value of tex_classes lut ruins memory:
TEX(PRRR_MEM, NMRR_WB_WA,    NMRR_WB_WA, 0),  /* 0 - ATTR_WB_WA */ - zeroes stack mem on TLB flush
TEX(PRRR_MEM, NMRR_WB,    NMRR_WB_WA, 0),  /* 0 - ATTR_WB_WA */ - zeroes stack mem on TLB flush
TEX(PRRR_MEM, NMRR_WT,    NMRR_WB_WA, 0),  /* 0 - ATTR_WB_WA */ - DOES NOT zeroes stack mem on TLB flush
TEX(PRRR_MEM, NMRR_NC,    NMRR_WB_WA, 0),  /* 0 - ATTR_WB_WA */ - DOES NOT zeroes stack mem on TLB flush
Need further investigation....
Any clues?
Stan
Stanislav Silnicki wrote:

STM32MP15x port current progress:
... it took some time to solder down the probe and establish conveniences with remote kernel debug...
So far, I need to understand, whither or not I face an expected behavior?
It looks like tlb_flush_all_local() (https://github.com/freebsd/freebsd-src/blob/525ecfdad597980ea4cd59238e24c8530dbcd31d/sys/arm/arm/pmap-v6.c#L512C14-L512C14)
destroys stack memory, where return address is stored, so when stored lr is poped into pc, it is 0x0....
here is a dump of my debug session around that code:
508 cp15_prrr_set(prrr);
(kgdb) i f
Stack level 0, frame at 0xc0784598:
pc = 0xc0557b44 in pmap_set_tex (/usr/src/sys/arm/arm/pmap-v6.c:508); saved pc = 0xc055254c
called by frame at 0xc07847e0
source language c.
Arglist at 0xc0784590, args:
Locals at 0xc0784590, Previous frame's sp is 0xc0784598
Saved registers:
r4 at 0xc0784580, r5 at 0xc0784584, r6 at 0xc0784588, r10 at 0xc078458c, r11 at 0xc0784590, lr at 0xc0784594
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) n
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
509 cp15_nmrr_set(nmrr);
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) n
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
512 tlb_flush_all_local();
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
_CP15_TLBIALL () at /usr/src/sys/arm/include/cpu-v6.h:147
147 _WF0(_CP15_TLBIALL, CP15_TLBIALL) /* Invalidate entire unified TLB */
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
tlb_flush_all_local () at /usr/src/sys/arm/include/cpu-v6.h:340
340 dsb();
(kgdb) x 0xc0784594
0xc0784594: 0x00000000
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513
513 }
(kgdb) si
Polling target stm32mp15x.cm4 failed, trying to reexamine
Failed to read memory at 0xe000ed00
Examination failed, GDB will be halted. Polling again in 100ms
Program stopped.
pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513
513 }
(kgdb)
The address, referenced from error message (0xe000ed00) is mapped by STM's address space to "DDR extension (CA7 only) or Debug" with debug assigned to Cortex-M4 coprocessor.
I'm not sure, that it is an unexpected behav. (it is my first attempt to port to armv7), so need an advice.
Any?
Stan
Stanislav Silnicki wrote:

my current progress of STM32MP1xx port attempt:
Basically, both options to boot ubldr and then kernel in SPL & TF-A modes of u-boot are supported.
Initially, when I stated from TF-A options (security supervision from arm's trusted firmware os) I stuck with
this line: https://github.com/freebsd/freebsd-src/blob/501bdf3001190686bf55d9d333cb533858c2cf2f/sys/arm/arm/locore-v6.S#L371
control does not seem to reach beyond that point. I tried to enable the led with this assembly, which works anywhere else:
  /* prepare to use LED @ GPIOA 13*/
  ldr r0, =0x50002014
  ldr r1, =0xFFFFDFFF
  ldr r2, [r0]
  and r2, r1, r2
/* Enable caches. */
mrc CP15_SCTLR(r7)
orr r7, #CPU_CONTROL_DC_ENABLE
orr r7, #CPU_CONTROL_IC_ENABLE
orr r7, #CPU_CONTROL_BPRD_ENABLE
mcr CP15_SCTLR(r7)
DSB
  /* turn on GPIO LED */
  str r2, [r0]
Control passes if I disable data cache ORing instruction, but then hangs on setting of new TTB couple lines below...
I thought it was due to security access control from TF-A, but it behaves the same w/o.
Any clues or expertise from other platforms are highly appreciated.
Stan
Stanislav Silnicki wrote:

Hello, I need an advice on the intial addresses layout when booting the kernel.
As I understand, ubldr is the proper way to boot the kernel.
What is the correct address to load it, given that I wand to keep default KERNVIRTADDR (=0xc0000000) intact?
The u-boot loads ubldr this way in my current setup:
// FreeBSD version of environment
env_set("baudrate", "115200");
env_set("console", "ttyS0,115200");
env_set("stderr", "serial");
env_set("stdin", "serial");
env_set("stdout", "serial");
env_set("autostart", "yes");
env_set("loaderdev", "mmc 1"); // fbsd's ubldr treats our second mmc at index 1
env_set("bootcmd", "fatload mmc 2 0xc0000000 ubldr && bootelf");
then ubldr leads the kernel from mmc and passes it the control:
Loading kernel...
/boot/kernel/kernel text=0x1b4 text=0x5b8530 text=0x17d91c data=0xa4a60 data=0x0+0x20c000 0x4+0x88810+0x4+0xe9d98|
Loading configured modules...
can't find '/boot/entropy'
can't find '/etc/hostid'
Using DTB compiled into kernel.
Kernel entry at 0xc0400200...
Kernel args: (null)
Then I could correctly pass the init of MMU and get into translated mode only with setting KERNVIRTADDR = 0xc4000000. It looks like kernel and loader clash somehow.
So, just need to understand what is best option to load ubldr to? Will it affect further routines?
Stan
Stanislav Silnicki wrote:

OK, I got the idea!
As I realize, there is a minor bug in dtc, which affects compilation of stm's originated DTBs. I think it is best to make a PR into https://github.com/davidchisnall/dtc, which I'm discussing with repo owner already. Please tell me, that I need to post PR into FBSD source tree if it is a shorter way for my fix.
My current setup is based upon QBASE1 from Karo-Electronics, but there is no goal to support/debug all peripherals, only a subset, including USB, I2C, SDMMC, DSI (and GPU, if lucky).
https://www.karo-electronics.com/fileadmin/download/Datasheets/QSMP-QSBASE1-Evalkit.pdf
The vendor (Karo) supports only their Yocto based Linux distro. I spent some time to prepare TF-A & Uboot, capable with booting from SD card (that is more robust approach, as I think). STM does not promote/support non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it is pretty cumbersome path, I had to pass. I think, it will be easier for me to prepare some sort of README to support customization of uboot for STM's port and dig it somewhere in SRC rather than  ; ; ; ; ;try to post PR's in those repos... Not sure, anyway.
So far I'm struggling with uart and early_printf...
I'm mixing this activity with my current occupation, so I don't expect rapid progress.
Thank you for clarifications! I'll try to do my best!
Stan
Oskar Holmlund wrote:

Hi Stanislav,
Please resend your message and CC the arm mailing list. It might be interesting for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think you stopped working on the STM32 port.
You should always keep one terminal up n running % man 9 style :)
https://wiki.freebsd.org/Phabricator will give you some information.
Its good if you get to know the people active in the ARM area, just keep an eye on the mailinglist and you will notice some names. If you have the opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even more people.
Join the IRC, for example on efnet #bsdmips is a good channel for ARM stuff.
Start with small changes and you will get feedback. From there the experience will grow and you will get into it all.
Correct, the device-tree import is from the Linux kernel and there is no prior work for the STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD either.
Probably because the STM32MP15 is the first(?) application SoC from ST?
1) hum? Do you need that for the reviews? It should be in SRC
2) Target branch is probably main.
3) It depends, if your custom board is opensource and availble around the globe through mouser/farnell/.. I dont see any problem. Otherwise pick the board from ST that you used as a reference when you developed the custom board.
For example in my day job we have a custom board built around the octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black wifi. So the code thats goes into the FreeBSD project are all tested on the beaglebone boards. The stuff we need for our custom board like the device tree is keept as local patches in our inhouse build process.
//Oskar
2023-10-28 14:25 skrev Stanislav Silnicki:

Hi Oskar!
> can you point me some guidelines to help myself to fit development
process? I'm sure, there is mature dev. culture around FBSD and I'd be
happy to make my contribution coherently from the beginning.
> So far I'm done with setup of my account at reviews (keys, 2FA, etc.)
> As I understand, there is no considerable progress with STM32,
although I have noticed, there are some DTS imported into the project.
> > Indeed, several major questions:
1. repo url?
2. tagret branch for patches for stm32 hw?
3. is it possible to target custom board from our project, or I have
to ensure support for all dev. boards, provided by STM?
> Thank you,Stan
> Oskar Holmlund wrote:
>> 2023-10-27 22:33 skrev Stanislav Silnicki:
quote class="gmail_quote" type="cite" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>>> Hello!


I'm porting onto the subject hardware. So far the progress is
modest,
while the system boots (without console although...)
One of major issues is hardcoded value inside locore-v6.S. Here
is my
relevant post:
>> > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
[1]
What is the best way to proceed? Patch, vendor kernel build,
something
else?
Stan

> Links:

------
>> [1] >
> https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
>> Hi Stan,
>> Upload your patch to reviews.freebsd.org
>> Love to see your other patches for the STM32MP15x.
kquote>


>> //Oskar







<

<
>

------sinikael-?=_1-17004306876680.537296210982912-- From nobody Sun Nov 19 22:06:33 2023 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 4SYPqt4tckz51Pcf for ; Sun, 19 Nov 2023 22:06:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (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 4SYPqt1n2jz3S5Y for ; Sun, 19 Nov 2023 22:06:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1700431607; bh=R9krJCwxepZqkI5dMCGKbeat2zIchuuM+SWOtmgkmVA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=d1v4Q5Ox3eztCGyi8ulTEVd6C/qNf1tgMP3rUhWIl4q29Onpc7VgDNvWgsgIThGtvxdd0u9oyoiEGu83UORXl1xmG52/0u1I+eWrBi5B8fTgML41TuGNbISj7T4JtQSMcOjbygT9CLzKiKQVWHZZIWwKTsQHIeH6hfb7SL109Q1mYCHPyQLgdyqyYwz+eUorWb4oIwS60Jmjw6Wao9jb98HCf8L41dO22RJNY240s9VUISYPBwqbjsxt62DEgN4cdp15/sigScF2GUsKOYM+U06jvCupLMRWJQWaEO9AdHHM9MnATtavm098k5vBfiiCdhka5wocJU1onsDzmOfTrA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1700431607; bh=fP2olCXJUSXUpMvyJfGr6aIUVOHqQ+TWCr4X3oEAb88=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=HI1hrznUqmZKsmEpNduy/vNxBJcHV+AjE000kGOE6GCGLO3KCP8K+5V1C3jiNfAS7T1cNzDVRmw9kNIfPUA5QPvAP4xI9RWBfq9N62gUnJqbpUF8lGFqFklRmbTYZdS/pP/My26vel0qkbiNDw/wnTVVA94/V9epvs7JZ1ihccXVU9TQHDxHxxhUiIQj0wCPLG9d2Y7SbnNNh2mGNq5DuWT76WCS5QEtyxbhJqP9LrienWUuB7V8dkgp0IBnvZvoz9NckRLzMpR6EMI0wxDgXgNj9Ug7rphXKlpIdG2PXhYLn+/DbPgXFulQJXmhz5/TXR+uCe8j5Ed97XDZvFzoqA== X-YMail-OSG: oh_M0rQVM1kD5UiprKgsbphMTrHbyV9anUK.AGjm8yZqqpzlb0ydFXr_Gd0NHrg Qk2Pgzi60eeyYd6GoftdQ8N0aOCCMQARFOZhtCklj8uJig1WL1XRqxR8D7.t9FqmfC5A3xVqOWV6 0iGHg1BjV2QEIn6VGxqbcWPYl7yR_3SjuTGkIGhZiP65MMXmAGTMWZ1VtZusL9H8ga7_z1ESouJT v.aWzGgZkzA_uZ_6XZCI3l9RiMJ7nb5MzwylEQBfZG3Xk0.4duZrW_SfpOzHT4tLKB5wS2RHgxdH ZfP7cftSk_ixZd5sOn3my7TVXXwnVflVTNDc4Mce6.E2VNG2r9SYiwEhA9p2JldU.IBv.Zs4szew G8NdMb2ESjnKhd9vPqKh8a8w1jbBASvXespyHidi_xWwETh1QZEnj_YJlXIonDQL5.tdZTnu_0rM ilAVgUBCNIaGtQRNJkb.P0UOMP0i509x.A4nzuNo3.FDQGgOudG6X5qWshvkQzDYKr6Ko5qjnsMX D2T8.mbmOrSGVHcy.6x.G39pz7aITp9WnVZzLxk6W0DqB94igjYRoFhfVCv8yu_7QtdBYw7kLGYP .bD3QPBcVu.xAQq8053g0ygKGFJR4BT3V5JKcPLDX7CIn9kT9nKtHu1EeP2ejygrUW2.08m.3qlK nAoVOxJPvUFV8eL3Ob_QCo397HJyHWVFjv3EgHuEzqVYxYgTboelxwLE5df3SZqBf5YkMvJ.DFtN ot_v4bVaK5RVM.anrLvcqzK8LDrAiTUQcC2fTqxleqmmiks04KHGIAARx9v6K4HFrg1uH2B9G5B0 GbPnFKAAbZ2H.e.QYXUW0WXXToIK503RoQLVIBt6uxomHnGAz35Dz.CKVQZMPMf1oNWlvBa3R.0w 7GC2NAIVSXls7MuWedbAYbVyddVhd9uzfwwJvIeyrPyj6tiRZeoW4lmWUUzV6YfQvuL0XBv32ZzE LXJmztIHulNcTUe96VDzgTWn9wosc6eko9UxeFZm9X9IJ1Y0uqy.J1C1IHVscrXFiK3hP84cWl1t 5NRDuDMiHM9.lTQrGBDB3LKfwQ3RHnCQivITdJLLGxOmNZ5jlP5N5Wnq.lMxt5vHaXiGB7h_k55M QhYX5CizpSJuHGQbO_FDHXxhu5bjXIgwzoQE1lI._rfFNmN_jgLHRHD2MAMYRyzOJ2I3_qesg4Bq h92sq4CyznQHVYOHvSqyGPzJR7heKCrzmwCLy8iZEUOcyqQwW4zA0rmjdm3G1k4_4w5VH5t5WwaH H4FgDPujbAYfTjoPEHRnnt6J93FjbJnCSWu2Skw1Ehlq7_W6VHe2Q2rOOFMfZQeHw1dztUWgqbeJ DIEiXXjGlSvVtUlRy1OlPAz5kpiXfJubesdEaoLAKKVfVJVcLn74swJKcP11BmOvTG8xz8YnS2Ay oa_J8oA.7LKoZp0VoiAOEsA53CEAH52CiwbHVKMuz3b_xlDajlNrXH_1l3e5e07sLXIqmZ.soB.y _UENfAme.KJ8GFjJcbuXreauXDE94LZ8yZYQG5D_fODryHrJzcDvPjWW4GVRJDtvG4CRjJ3NkItr 5vLGzfdH0uzWkVabRg.kzwLF5Ium07z6SXSC5ONVh_5f6lbZN4_MHtXuJzotf__XIdXRJqvQX5y. rr5WPI7qG6leoW8K16f3ibUvskcVOwTkpun0zPkWJAyz5D1AYgw4StYcTgEimBzwuT_eF67pIO5b U_02Sm0IfAPA0bUz2NGseTdPW4fRcnq2TuNjadp3BJmon1S48dnnQdJye9tdoZbsblqrjQcF0bBZ l53DlbTjkP5W._iweGLBIVLNF0koCNfl5LW_pqtwdkZuXzTCES8oNza31mEoPk0eTAeYEdcWLD2j nVAauCIUfz94zZV8Tcg2YvLlhFmJti4rapjFNzZVJbXWJlNU01tpxP4CM138O4jxWiHJ454uKVgZ MjnBbPFnmp8nZAjBz6pDvTbXvwDXYhM9LCMUeAfJYuss6FL_qyl18AlXcbmBvWdN3C4NKKSdE.IG o4eU5bAVhinbON4jmnJpN6QE.1.qGotisXyb8U18sh09oOLpNDG7ieb7Btvtc6ddcvH_YBE4GpbV uBraXp44K34X10qeLCHqDype2kdfmlAMDnhw.eLszf667PxBKdyA3H5xGC0Xq13vyOhTL273scu9 HPDfd1RW1FqMM8LnDYWkosChgp6AzcdZgNgJ2d9muJvEKyvtcig01xcVmx6RsHRGxITVKX05_M6P 1v1s78e22YmBz3Gvif.Ko99.MtFwY.r25P4kha4qb9J9aNhNFPzv8ZTVYPlf7WZNZPDFHT.8bqN4 mYw-- X-Sonic-MF: X-Sonic-ID: f85fa894-efba-4286-abc1-97559d162117 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Nov 2023 22:06:47 +0000 Received: by hermes--production-gq1-59b5df67b6-hs7p7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 93719f829f57fc7069d2934637028908; Sun, 19 Nov 2023 22:06:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: Setting CPUFLAGS breaks aarch64 13.2 -> 14.0 cross compile due to invalid -mcpu= From: Mark Millard In-Reply-To: Date: Sun, 19 Nov 2023 14:06:33 -0800 Cc: FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: References: To: John F Carr X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4SYPqt1n2jz3S5Y On Nov 19, 2023, at 10:59, John F Carr wrote: > I have been building 13.2 with the following line in /etc/make.conf: >=20 > CPUTYPE?=3Darmv8a+aes+crc+sha2 I've not found a way through this (so far), at least using documented inteerfacing techniques, but I did run into what gcc13 does with -mcpu=3Demag : its assembler run is given the likes of . . . /usr/local/bin/as -EL "-march=3Darmv8-a+crc+crypto" . . . This corresponds to the aarch64-cores.def having: . . . /* Do not swap around "emag" and "xgene1", this order is required to handle variant correctly. */ AARCH64_CORE("emag", emag, xgene1, V8A, (CRC, CRYPTO), = emag, 0x50, 0x000, 3) /* APM ('P') cores. */ AARCH64_CORE("xgene1", xgene1, xgene1, V8A, (), xgene1, = 0x50, 0x000, -1) . . . =46rom what I've seen Linux classifies an example emag with: Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x50 CPU architecture: 8 CPU variant : 0x3 CPU part : 0x000 CPU revision : 2 (OS's and compiler toolchains need not use the same terminology.) =46rom what I've seen, Linux classified an example xgene2 with: Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x50 CPU architecture: 8 CPU variant : 0x1 CPU part : 0x000 CPU revision : 0 (gcc has no xgene2 name) I got these from: https://github.com/hrw/arm-socs-table/blob/main/cpuinfo-data/emag https://github.com/hrw/arm-socs-table/blob/main/cpuinfo-data/x-gene-2 The following notes may or may-not help in some incomplete/less-supported way. What I've done is more limited (text taken from an example context not matching yours): ACFLAGS.arm64cpuid.S+=3D -mcpu=3Dcortex-a72+crypto ACFLAGS.aesv8-armx.S+=3D -mcpu=3Dcortex-a72+crypto ACFLAGS.ghashv8-armx.S+=3D -mcpu=3Dcortex-a72+crypto Sometimes instructions need to be enabled so that the OS code that tests for functionality can produce the instructions that might fail, in turn allowing the detection to work. Thus, optional parts of the architecture can need to be enabled in certain places. I've also done things like: # Use of the .clang 's here avoids # interfering with other CFLAGS # usage, such as ?=3D usage. CFLAGS.clang+=3D -mcpu=3Dcortex-a72 CXXFLAGS.clang+=3D -mcpu=3Dcortex-a72 CPPFLAGS.clang+=3D -mcpu=3Dcortex-a72 that avoid the likes of +aes+crc+sha2 with .clang use. [I do not do these sorts of things for the ThreadRipper 1950X or Ryzen 9 7950X3D, just for notably lower performance contexts. cortex-a53 (strict in-order) vs. cortex-a72 (not in-order) are rather different for optimization, despite being the same march, for example. I even ran into a FreeBSD memory model handling bug with my use of -mcpu=3Dcortex-a72 compared to a standard style build. A cortex-a53 never showed the issue. A cortex-a72 only showed the issue with code optimized for the out-of-order handling. So of the 2*2 possibilities (mcpu vs. hardware) only 1 combination showed the problem. (The USB subsystem bug that lead to the memory model mishandling was fixed. Such testing contributes to why I do such things for arm.)] Somewhat closer to your type of context is an example where llvm misclassifies the features of a named cpu and I adjust things to be more accurate: # Any use of the .clang 's here (e.g.) would # avoid interfering with other CFLAGS # usage, such as ?=3D usage. .aarch64 and .armv7 # do more, staying consistent with not # lib32 vs. lib32 context. CFLAGS.aarch64+=3D -mcpu=3Dcortex-x1c+flagm+lse+rcpc CXXFLAGS.aarch64+=3D -mcpu=3Dcortex-x1c+flagm+lse+rcpc CPPFLAGS.aarch64+=3D -mcpu=3Dcortex-x1c+flagm+lse+rcpc CFLAGS.armv7+=3D -mcpu=3Dcortex-a7 CXXFLAGS.armv7+=3D -mcpu=3Dcortex-a7 CPPFLAGS.armv7+=3D -mcpu=3Dcortex-a7 LIB32CPUTYPE=3Dcortex-a7 ACFLAGS.arm64cpuid.S+=3D -mcpu=3Dcortex-x1c ACFLAGS.aesv8-armx.S+=3D -mcpu=3Dcortex-x1c ACFLAGS.ghashv8-armx.S+=3D -mcpu=3Dcortex-x1c Note the lack of use of .clang for the above. This is clearly not using the primary control interface documented for the build system but is how I deal with my tailored builds. > This matches my processor (Ampere eMAG), which llvm does not > know by name. >=20 > Now I want to upgrade to 14.0. I can't build from source on 13.2. > Compiling 32 bit objects fails because $CPUTYPE is not valid > for armv7. Setting CPUTYPE_32?=3Darmv7 does not work either. > That generates an invalid compiler option -mcpu=3Darmv7. > Setting CPUTYPE=3Darmv7 needs to generate only -march=3Darmv7 > and not -mcpu=3Darmv7. The make infrastructure generates both. >=20 > Using an empty string for CPUTYPE_32 did not work either. >=20 > According to /usr/share/examples/etc/make.conf, I should be > able to use CPUTYPE=3Darmv7. >=20 > Is this supposed to work? Is there a /etc/make.conf variable that > sets -march=3D but not -mcpu=3D? >=20 >=20 > # Meta data file = /usr/obj/usr/src/arm64.aarch64/libexec/rtld-elf32/crtbrand.o.meta > CMD cc -target aarch64-unknown-freebsd14.0 = --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp = -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common = -march=3Darmv8a+aes+crc+sha2 -mcpu=3Darmv8a+aes+crc+sha2 -m32 -target = armv7-unknown-freebsd14.0-gnueabihf -DCOMPAT_LIBCOMPAT=3D\"32\" = -DCOMPAT_libcompat=3D\"32\" -DCOMPAT_LIB32 = --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp = -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/lib32 -Wall -DFREEBSD_ELF = -DIN_RTLD -ffreestanding -I/usr/src/lib/csu/common = -I/usr/src/libexec/rtld-elf/arm -I/usr/src/libexec/rtld-elf -fpic -DPIC = -I/usr/src/libexec/rtld-elf/rtld-libc -mfpu=3Dnone -g -gz=3Dzlib = -std=3Dgnu99 -Wno-format-zero-length -Wsystem-headers -Werror -Wall = -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual = -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts = -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time = -Wformat=3D2 -Wno-format-extra-args -Werror = -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable = -Wno-error=3Dunused-but-set-parameter -Qunused-arguments -DLOCORE = -c /usr/src/lib/csu/common/crtbrand.S -o crtbrand.o > CMD CWD /usr/obj/usr/src/arm64.aarch64/libexec/rtld-elf32 > TARGET crtbrand.o > OODATE /usr/src/lib/csu/common/crtbrand.S > -- command output -- > clang: error: unsupported argument 'armv8a+aes+crc+sha2' to option = '-mcpu=3D' > clang: error: ignoring extension 'sha2' because the 'invalid' = architecture does not support it = [-Werror,-Winvalid-command-line-argument] > clang: error: ignoring extension 'aes' because the 'invalid' = architecture does not support it = [-Werror,-Winvalid-command-line-argument] > clang: error: unsupported argument 'armv8a+aes+crc+sha2' to option = '-mcpu=3D' > clang: error: ignoring extension 'sha2' because the 'invalid' = architecture does not support it = [-Werror,-Winvalid-command-line-argument] > clang: error: ignoring extension 'aes' because the 'invalid' = architecture does not support it = [-Werror,-Winvalid-command-line-argument] >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Nov 20 00:15:29 2023 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 4SYShQ0MTmz51Ypx for ; Mon, 20 Nov 2023 00:15:34 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4SYShN69MNz3bZ5 for ; Mon, 20 Nov 2023 00:15:32 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm1 header.b=TINZ8CMc; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=ewJd1GLo; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.25 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5CEF65C01A7 for ; Sun, 19 Nov 2023 19:15:32 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 19 Nov 2023 19:15:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1700439332; x=1700525732; bh=QW Fk4wdW67x5BwtAWpLakVDuluYOZZ7yp2NZ3z3KWEw=; b=TINZ8CMc5cqcAzmQGT /qT5VcMe66iqqrY1/2Ol8C5F08vA6G8v0QEVZ+VPzDarPRsE9PZywaIZOOkiepfa nMPQVxX61FqyMx5/4ufcXwS12MbNvgiq3UuEAFuQQBrlpVIApIqLltspe9cbqp42 PYfD1+toJO7HIHYLSGsZ27txr++x8B09MBKCdSAGqrjtm74H9ctozrHalnSPeODF OEO2Oum5yVfbRYerAciJ6dLaGhHxoWcJbD1G4p8RjZZBCOVictTStrzYl5LZM5FG 5md6rWPadTwRq1DjX1QWtoryW5p7qGUSCRzBGeD+dQ6c/dztW5ISwGl2axdu6Ubr t10g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1700439332; x=1700525732; bh=QWFk4wdW67x5B wtAWpLakVDuluYOZZ7yp2NZ3z3KWEw=; b=ewJd1GLooM6nkfEhSZJNE4gukStHp 3Zh+MDaniAXdQgiq1r/biMaSLXkEGCdZ2IugQPk7c+dXIs82WhcYEz/fnceciVa4 MGo9XiVIlvaco7/nnNl8xIRHTPBVWutzViLLJxVJpnuIDlBpZO7A2MmqUFdVmXZo ygi11zTtz7PQ6H4eDnZzY8IHoC7OIhGr09Ui4wOZzs0ooEfUBFB0mZTee9Mkh5OK 5EQyUTsrq3HxCLWccdog0a4EyOy3jyZ+PCj+7I5rSdtEGXLzanBD/YAsT+9O0XAa QNd8OTZr3fQAfkwdUqUu9QUSNejS0jgs+ttjcBAJJNTnchOi7XuDNtzTw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeghedgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep vhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 19 Nov 2023 19:15:31 -0500 (EST) Date: Mon, 20 Nov 2023 00:15:29 +0000 From: void To: freebsd-arm@freebsd.org Subject: Re: pkgs for FreeBSD:14:aarch64 latest are stale compared to quarterly Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <49AAADF7-2A14-4922-AC56-B763EF0C6FB1@yahoo.com> <579E2DA6-8496-4E1C-A993-885C82C0B780@yahoo.com> 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=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <579E2DA6-8496-4E1C-A993-885C82C0B780@yahoo.com> X-Spamd-Result: default: False [-4.70 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.25:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4SYShN69MNz3bZ5 X-Spamd-Bar: ---- On Sun, Nov 19, 2023 at 10:21:19AM -0800, Mark Millard wrote: >NO! You seems to have missed the earlier indications of which >FreeBSD build servers do which builds (ampere1 vs. ampere3). >So making that explicit in the summary: > >31 Oct 2023 finish quarterly on server ampere1 >02 Nov 2023 finish default (a.k.a. latest) on server ampere3 >15 Nov 2023 finish quarterly on server ampere1 >18 Nov 2023 finish default (a.k.a. latest) on server ampere3 > >So: over 15 days between finishing 2 140releng-arm64 builds. Ah ok, understood now. Sorry I misread earlier. -- From nobody Mon Nov 20 15:27:14 2023 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 4SYrwl5088z51Rfx for ; Mon, 20 Nov 2023 15:27:35 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SYrwk5WJ2z4PYQ for ; Mon, 20 Nov 2023 15:27:34 +0000 (UTC) (envelope-from jfc@mit.edu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mit.edu header.s=outgoing header.b="iPvFXgH/"; spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.13 as permitted sender) smtp.mailfrom=jfc@mit.edu; dmarc=pass (policy=none) header.from=mit.edu Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id 3AKFR5Bq031924 for ; Mon, 20 Nov 2023 10:27:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1700494052; bh=NRFBZi3brR+1r7YDRxFJwEr1oOystHS6aq7Jz33FAbg=; h=From:Subject:Date:Message-ID:Content-Type:MIME-Version; b=iPvFXgH/B3wduv6wpAKQhDLBn/J6t9RN7kPyVIQR6jWoS+RXVK5fSp0tGC8RhqbC/ 9bjCoK6Aw7d2cOjDoEwJLOzIQ2x0sUKmytcNcxDHTiCy5cRfLsGQ9bI/CtoaML4Egg 2zBcsdtU2ksZruJrgLf7k5UvT9xq1IHKavz5W0/zsCinWsXSbF7gAd9Dy/2Rnads6Q jG/XpgTemPr/cD1YJucrhY380SRRd9cH6VF/e7OACBs4veN9PE+mOdie4H5vDRPEkt tcwDgC0PgrG1KtzfAZlXRwGgFyLZQR6Dgqa2z22QSS4KOuTXPYJqZWZUCx5RUT+2C/ wK06k9VLiH6Uw== Received: from w92exhyb3.exchange.mit.edu (18.7.71.73) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Mon, 20 Nov 2023 10:26:51 -0500 Received: from oc11exhyb7.exchange.mit.edu (18.9.1.112) by w92exhyb3.exchange.mit.edu (18.7.71.73) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Mon, 20 Nov 2023 10:27:17 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.169) by oc11exhyb7.exchange.mit.edu (18.9.1.112) with Microsoft SMTP Server (TLS) id 15.0.1497.48 via Frontend Transport; Mon, 20 Nov 2023 10:27:16 -0500 Received: from SA3PR01MB8450.prod.exchangelabs.com (2603:10b6:806:382::17) by BY3PR01MB6770.prod.exchangelabs.com (2603:10b6:a03:360::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.28; Mon, 20 Nov 2023 15:27:14 +0000 Received: from SA3PR01MB8450.prod.exchangelabs.com ([fe80::79a2:b3b5:bcdf:bdf0]) by SA3PR01MB8450.prod.exchangelabs.com ([fe80::79a2:b3b5:bcdf:bdf0%7]) with mapi id 15.20.7002.026; Mon, 20 Nov 2023 15:27:14 +0000 From: "John F Carr" To: FreeBSD ARM List Subject: Re: Setting CPUFLAGS breaks aarch64 13.2 -> 14.0 cross compile due to invalid -mcpu= Thread-Topic: Setting CPUFLAGS breaks aarch64 13.2 -> 14.0 cross compile due to invalid -mcpu= Thread-Index: AQHaGxqM72Tzgo01YkO/V3ykGJU+5bCDVdIA Date: Mon, 20 Nov 2023 15:27:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SA3PR01MB8450:EE_|BY3PR01MB6770:EE_ x-ms-office365-filtering-correlation-id: a5372e6d-7595-4ea0-ac3b-08dbe9dd2c96 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wpe2URdLR2Qn19F1auMgFjvhmHp2Nd7rJuBmBSgg5up6R5PNHz/dsXpXKOgrwoPXp2LUNiedlZ8l0pmTj2HaIlImmqzmcTs9X6AJ0Fyj5hs9XBZOmT3krd/nPibXaTILhr5gT+V4GoywhAo6kTLVFeXAnPMS6UrFGJpA21Ex2G0GBwyOrrCGIt/9x5Dj9DHCnQm9985zjQBZo0yhftJ9zYRrzMT2V4+/CbeOR6WeiVqzdg5cyuKyle/SIHgQBfmlFqTchTgxkJF29y3QrydwhwEXILtMYN0tFF+2OOIdb/dknz/u35+7X/nSBPBO9R1R04Jg8GUA9HgMGYSrpfssxgmHv+gP3iN+bjKmddtcNMqcUr2PKj22CqoNKA7Enr5wsJFOSx50c1xIzQw1EkEoTJqHgNaztzIt6HHg+/NYC7amNeTtVnK4XnuR3i19xYrPKtM2wdsAUyN71szNfLObtVu2At2KVMTMwg+G7lOTlItSHaZzZSI3FwRLqbkQhLsPCDpIbw+0XnfupkGL2df98CO4CDLVdeZab4asDGOS+N1ppobSI3dqXBxh/JauODsbY9HwJNBkUgTQOCYVF3ydkDvNVmQjj5LPKlkIBOcpYiUpsBDLisdfzoU+MTsnnpNe x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR01MB8450.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230031)(136003)(39860400002)(376002)(346002)(396003)(366004)(230922051799003)(451199024)(64100799003)(1800799012)(186009)(75432002)(76116006)(66476007)(66556008)(66446008)(66946007)(91956017)(786003)(6916009)(64756008)(316002)(53546011)(6512007)(36756003)(71200400001)(6506007)(2616005)(478600001)(6486002)(38070700009)(38100700002)(122000001)(83380400001)(33656002)(86362001)(5660300002)(2906002)(41300700001)(8676002)(8936002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?vALl9qEKEWkeXBaELFRcEQLuJzzRbsRo+anFMaT0qA/7Nyhj3v6T4ahkJat2?= =?us-ascii?Q?js4hEyPQG3Dcn2es8TocZuwE98xWoHzA+KwPSo/VYtFecd0PE63S+I+nzs+7?= =?us-ascii?Q?uhbjll/sUgwzkwwWNZjAoXgYSVWVFpBJ5EJh26ypvfHR1NXFF1WvwfFIbAOA?= =?us-ascii?Q?vs5cS/founn7qZgkTmIRxK1lpun+jaPQMNZEPR/f4M03IApe7w7iSz5I3sFN?= =?us-ascii?Q?GlPKKoLqPOo0ZIxpUc3kEjVeXyTKu4iPgKgqCeYM+kqcMRQbUdeQkGZKIw2p?= =?us-ascii?Q?LDUE6m3bLVIX6ck2Zi8qCEHhlxVYOq2gTmXAqpBbnR2sQmvbq2++JPuA/Y/z?= =?us-ascii?Q?9bT89ARmqPKeaf5zdAJIG1HMit+9csF8auYoJpjnbvzgE5147F5sAB57HRQA?= =?us-ascii?Q?WDalLWQ4AX87urkdjbk0yP8E5GdrmP3wF6m2qgRLap7j5la1k2lNndwNynFA?= =?us-ascii?Q?2w9xBhTi6fY+nNi/GFv5Ib6kgO3ILUNqc0RLZJ2/QsjkycU788h7HBAevVY1?= =?us-ascii?Q?DqD4+vnjl9IM0k4CECIAzX1285CL1MsTKi2paqZLiS3GuJXBm2CwHgOVKh3G?= =?us-ascii?Q?HmX5gslfWkEOKBzI8hmRUN4MD+8JZYmAsBvckLnl3PV9UflOYcX0HH5vF+yA?= =?us-ascii?Q?FWF0TAgfH20DC8Gaa1+jHNWnVK8HR1WC/2b6nMCmPuoEMAbWCxowN43zOhac?= =?us-ascii?Q?VTa5llZREEXg9yS9Uz7DLrwglywnVGhwuOZZjfGQ1Sqz5Wda/oo/sKpNpfBt?= =?us-ascii?Q?vqZY45IYauoQHj6iAEuLjxDaAWViX+z06K8JfUMKVFn9krjsxIrdy7HDIerE?= =?us-ascii?Q?PDCXtEMjmuyQfG3Hv0fhivy8l4yhATNoJCsWcBYan0bDKbKHvt28LVpVZ/HA?= =?us-ascii?Q?vpsDzeWhm2IktEJyfqlF9Yg/JU+dECk8cx3xQjlKO5eBwmlWNWlGCiIEkUQg?= =?us-ascii?Q?6yOQz1QAdtHGeYj59rhtfEwhkJ6b9WYLAbixEOxQGsJ47SByi7MfZk7Bbq/d?= =?us-ascii?Q?/WEqu3/gOgQWHvGC5fUWhJhj41IZClverSlcrV8FBaClxNMWzCKVWS15Hmbm?= =?us-ascii?Q?0n/J6qAfoiRl1T0TmD5oL9iZAmTPcI4eJ3yV8grWpx5ZfNlPewjjOioYZLHV?= =?us-ascii?Q?smBNdyljAvvuFTCA2/ivaVtxF7DaVRI2hQhAXjt913Oq538g/Rh6Ad/PYRBI?= =?us-ascii?Q?5M2DvatiYI3gEcvQyeXjrEicGqV7CQ/S8vPWZF3mADW0yra2KAf4In9pzg2V?= =?us-ascii?Q?DC0VsD0GNferLkqthz/41vDcyccsm4+hmBJcbtB7GNDHrymtVncLNn5WXD7s?= =?us-ascii?Q?LzdkUyvSmpGC127PFe5+5+OkmiXsWesnyMBN6H8pFMPpAORK6Bt4PbppK5dY?= =?us-ascii?Q?m2ocimGbXxvKcmISzhsKYrZ6wqJu07Xz5+hg9jKduJcV9SsBapHYIWpS6ctf?= =?us-ascii?Q?/YNKraSHFVgPPokEdyGGDgAfXGt3OSAdBjo6Jyi0m5GCDmYPlaB2ZOjeBZQr?= =?us-ascii?Q?jHj6zYWcjBqBhweK8oFAS01H/Ml8t2Q2pElyVaArGnfsGWqeyl/peQG+c5K7?= =?us-ascii?Q?iYALF9Y6vdIcqN0TrDBu3Al6YYT8BCtKvYFeMoTiDLqd25CXuD9yzbIdO0uO?= =?us-ascii?Q?wwynolU/4Nz54w/YAYN8BP4GI83JNxx8kH9Qq1keHv/d?= Content-Type: text/plain; charset="us-ascii" Content-ID: <4C5ED5F0CF3D58418FC627E405D0E355@prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable 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 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR01MB8450.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5372e6d-7595-4ea0-ac3b-08dbe9dd2c96 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2023 15:27:14.8115 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WeB7s3jBIioIQI4XP3PLKv8YaVK8tx+PyqoymUjjbGG4e8MzQACLDldMjKoK0LTf X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY3PR01MB6770 X-OriginatorOrg: mit.edu X-Spamd-Result: default: False [-5.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[mit.edu:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DMARC_POLICY_ALLOW(-0.50)[mit.edu,none]; R_DKIM_ALLOW(-0.20)[mit.edu:s=outgoing]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; RCVD_IN_DNSWL_LOW(-0.20)[18.9.1.112:received,18.7.73.15:received]; RCVD_IN_DNSWL_MED(-0.20)[18.9.28.13:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; DKIM_TRACE(0.00)[mit.edu:+]; RCVD_IN_DNSWL_NONE(0.00)[104.47.56.169:received]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4SYrwk5WJ2z4PYQ X-Spamd-Bar: ----- On Nov 19, 2023, at 13:59, John F Carr wrote: >=20 > I have been building 13.2 with the following line in /etc/make.conf: >=20 > CPUTYPE?=3Darmv8a+aes+crc+sha2 >=20 > This matches my processor (Ampere eMAG), which llvm does not > know by name. >=20 > Now I want to upgrade to 14.0. I can't build from source on 13.2. > Compiling 32 bit objects fails because $CPUTYPE is not valid > for armv7. Setting CPUTYPE_32?=3Darmv7 does not work either. > That generates an invalid compiler option -mcpu=3Darmv7. > Setting CPUTYPE=3Darmv7 needs to generate only -march=3Darmv7 > and not -mcpu=3Darmv7. The make infrastructure generates both. >=20 > Using an empty string for CPUTYPE_32 did not work either. >=20 > According to /usr/share/examples/etc/make.conf, I should be > able to use CPUTYPE=3Darmv7. >=20 > Is this supposed to work? Is there a /etc/make.conf variable that > sets -march=3D but not -mcpu=3D? >=20 The patch below fixes my problem and I have now upgraded to 14.0 without further difficulty. commit 9c92d91a3a617f262c9c6907038f34805e1b8ecd (marmota) Author: John F. Carr Date: Mon Nov 20 10:07:30 2023 -0500 Allow CPUFLAGS_32=3Darmv7 diff --git a/share/mk/bsd.compat.mk b/share/mk/bsd.compat.mk index 0c387bcb020c..85f6c6d5932d 100644 --- a/share/mk/bsd.compat.mk +++ b/share/mk/bsd.compat.mk @@ -65,7 +65,7 @@ LIB32WMAKEFLAGS=3D \ .elif ${COMPAT_ARCH} =3D=3D "aarch64" HAS_COMPAT+=3D 32 -.if empty(LIB32CPUTYPE) +.if empty(${LIB32CPUTYPE:Narmv7*}) LIB32CPUFLAGS=3D -march=3Darmv7 .else LIB32CPUFLAGS=3D -mcpu=3D${LIB32CPUTYPE} From nobody Thu Nov 23 12:15:58 2023 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 4SbcXR6bPwz527bM for ; Thu, 23 Nov 2023 12:16:07 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SbcXQ6m6rz3K25 for ; Thu, 23 Nov 2023 12:16:06 +0000 (UTC) (envelope-from jfc@mit.edu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mit.edu header.s=outgoing header.b=EwrX7iol; spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.15 as permitted sender) smtp.mailfrom=jfc@mit.edu; dmarc=pass (policy=none) header.from=mit.edu Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id 3ANCFuBh000515 for ; Thu, 23 Nov 2023 07:16:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1700741763; bh=y/sBTfbwwFGlGtA4ay19w+RbwIk/JmVza+gWk3hLdcQ=; h=From:Subject:Date:Message-ID:Content-Type:MIME-Version; b=EwrX7iolA3F7uplkdQcQIepXQyc7g+vqnFKdd0xCTIqIvxlWNpoSv6zoWGBpzg7OJ TFVsiUfsgZlIDSEwGY3kQfVWi0zyIeIMThixjBZcB+xssO5OW1GAfd3gQu3ForqHzf W5NYQzBQzoJPDjnTTrfkC4suYI+q77O1olVKDQUK2TKo+1AXYdapxMtfMogzSqSCUS bcQ97OmUtSI8Azjp6ALlUpLuWQcgjFj6CAVjTQOg1GwzBlSa1DFbmFDdBkUcypnoPn nwS4OHeZ17PLSx/vtFwbKEYsIwikB+UbR/FqG2ySbFlhqGDUUcVwo/OMcivbJY7+9z wNMK1IIF49VhA== Received: from oc11expo6.exchange.mit.edu (18.9.4.11) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Thu, 23 Nov 2023 07:15:24 -0500 Received: from oc11exhyb3.exchange.mit.edu (18.9.1.99) by oc11expo6.exchange.mit.edu (18.9.4.11) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Thu, 23 Nov 2023 07:16:00 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.169) by oc11exhyb3.exchange.mit.edu (18.9.1.99) with Microsoft SMTP Server (TLS) id 15.0.1497.48 via Frontend Transport; Thu, 23 Nov 2023 07:16:00 -0500 Received: from SA3PR01MB8450.prod.exchangelabs.com (2603:10b6:806:382::17) by SJ2PR01MB8553.prod.exchangelabs.com (2603:10b6:a03:55b::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7025.20; Thu, 23 Nov 2023 12:15:59 +0000 Received: from SA3PR01MB8450.prod.exchangelabs.com ([fe80::79a2:b3b5:bcdf:bdf0]) by SA3PR01MB8450.prod.exchangelabs.com ([fe80::79a2:b3b5:bcdf:bdf0%7]) with mapi id 15.20.7025.020; Thu, 23 Nov 2023 12:15:58 +0000 From: "John F Carr" To: FreeBSD ARM List Subject: Undefined __aeabi_uidivmod in 14.0 armv7 Thread-Topic: Undefined __aeabi_uidivmod in 14.0 armv7 Thread-Index: AQHaHgbQ5vyOOPdhD0yFmNvhz59tmw== Date: Thu, 23 Nov 2023 12:15:58 +0000 Message-ID: <0EBEB2B6-198D-47C5-8715-02F19EF5ED06@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SA3PR01MB8450:EE_|SJ2PR01MB8553:EE_ x-ms-office365-filtering-correlation-id: acb0aafe-0653-4c80-e630-08dbec1df346 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WKDOtRwTYqSOKbn2fw2AcrkNh1zxhuHRCXEl9im1pp9paa5F8t00BA6YKPhiD4+8DE0UVdACC4K8Wnz/MvpE6fZwkt7ae8DtvD+PNMjva93XvE9JPQeyFh94AcLaeNUdKrpPPfgrvEb0ySkzL6NHR2w1Blwn7mUI+zNr6an1RaghWmgDxEgE3bLkstEQS1nFifDAcPb/d1kE7WEv1RGdirhX2BPf5gWwqSrR0d4ME2MD9Cq7PODo1VOufaBqUlQZY6qRz0KFN6qKX1ne5IhfU+9lOM1m8glzM8r6TYLV5sKTXjVNyMjr/bVKilrafJr3XsYFDgSzSS6ODxABtCZqdL6mVNkh/4lx6nywKpkbQNRBFbNCn1IY1914jHMDiowESRXf5htSHcVr6yV1xYZIz1wBAHRQWkyDfF45v/CtOdlvbCjz2Hi3xxHssCWDmSkJACjk9fQHTAih2qBsGOT/aZ19k8N7vovn/vVnDNypv5RCFLkQOTMy1TznwJCw4akUvvBLzbWK7+BSLPeUy4KRy66WNMQL+oiJXs69cefNWMIGQquPEdpsqCBe6IXB+/rYTDZAAHAUTK0WLXP/uIMz2pOfYi/QRdpj4Um4S0IK5B0= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR01MB8450.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230031)(136003)(376002)(366004)(396003)(39860400002)(346002)(230922051799003)(451199024)(64100799003)(1800799012)(186009)(83380400001)(38100700002)(38070700009)(86362001)(36756003)(33656002)(122000001)(75432002)(66476007)(6916009)(786003)(316002)(76116006)(66946007)(64756008)(66556008)(66446008)(41300700001)(8936002)(8676002)(91956017)(5660300002)(2906002)(6512007)(2616005)(71200400001)(6486002)(478600001)(6506007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?sSNsXgewfuBuWcNimglLVw4ipVc3+yKHQmEYJUItNXuPuYfssDWd0Rd9ljAs?= =?us-ascii?Q?MZWPt//Yx/BV4H9lf791MN+Zd4tqfNuyVFtB3nk0j5n1nWLxiuC03N68kd7v?= =?us-ascii?Q?/Q5XlMMUgLi853vjVtukyEfibAK+UufOaUlHYAEN3ngxm/Pn2fNMUdBP23mC?= =?us-ascii?Q?yOjmMpCuBzD3ier9C6RtFXQOzvaNxgA2pcCM59F7mGmUjaE1DjeXkibaKcOi?= =?us-ascii?Q?wtnDsYtDEpzzaGslAoG0kXw/sfpFV4jHtutVywEmJ1DMS5GanMx1haigvcma?= =?us-ascii?Q?gryYyBSsFmXBBYDsSCQLC1lz5b0qk1FEXv3UnwtJD1/te21FVmkJIKwrajEf?= =?us-ascii?Q?Xxa8UsE4lguzZ4qLH2im6QvxegFjVMR0r53iu3IthpCOmmjeTDqUTGIigkt7?= =?us-ascii?Q?xOwHyWLZUJex2BCjI0VrhbJ46GSflERanMD2MhfXwCwZ6jDhRFxsSKf8YwOW?= =?us-ascii?Q?AqL81Imy7gqgR/HoYDIuyBVGcFdzK4XdYxu7Zs/K1+p5qRalbNrUeommhTpa?= =?us-ascii?Q?+O0gmr0TzVrLJdL17miibisJb+cf3anozTKtLIgjufumqUIjo0hpuvyWc5fm?= =?us-ascii?Q?s5faEhMx6lHdAMhiFYCSpFjGPx5MAWvEBqMFiJp+14Cicv/sDUnAOJKXIu8w?= =?us-ascii?Q?j94tpyiJPBQNplEmn1++dXKIrrPQvbVOXdSs+qVwu3Qm8tDJ7oBTtAzTD0F/?= =?us-ascii?Q?QTBVXWg2pKXSgB3DkXD3VJ2ASgegki4JI2oc2fLEWGMgMV7jthnwk5dvmSRc?= =?us-ascii?Q?FADz2Kth/GwKKHLvBovesXCJFZMYJ2x6B6zel7V60mXubssNQPYCeVPAZSXd?= =?us-ascii?Q?xiwjhidCOKtJupJ/GG0mdTV7vestzOPCnO0+l0KesZ7ggQMPTyT58yC+7voX?= =?us-ascii?Q?5caFIXjzBnPdwlaNkvBttoVWUXaQmY6XUq5uMRxJKkeXcI+XHNBQp2b43HhX?= =?us-ascii?Q?BFN66W0INkqRhB+TydWeXeyfkOMIrtzmo7SxqCwBVhwqdf5Hb9s1aY89IY40?= =?us-ascii?Q?1AXVsjdCvQCxKyuYbrh1p2768WK8Ppiq1n56xu5RlQ8+gnzwnzok1FgpZnSK?= =?us-ascii?Q?k99g3EscfNr5MwIi07gdgv8OjyZGEedbDoG3v40ydAmE+13KaCeWBLrS94qF?= =?us-ascii?Q?tJa6v4BqH8zmlCzz8fpgAqA0MQjcBGG8DyhTzyfEEccRv+Q3DbcbgXWN1p9B?= =?us-ascii?Q?dnmdRtSNxasoMS/Bt6REensmDfUYoJDhwGEhHLHS70087CKwIpmtcEt4A3QG?= =?us-ascii?Q?jk5Yt9zotwjLWT68AwuO8ZWRgUZuenjjQT+aVsodPjx758lC7xLUZYyGx2Ls?= =?us-ascii?Q?JwpC6ojJL+rCsfPtfcWRczo6yrke75hpylK+B6eZXZasrL4PxmM5uQ03SM3L?= =?us-ascii?Q?NL4l8SuwPxDRr6bhOonJ0z7Uvu2czgBDv5/wZgwu/n4CJqZzwVJQx3zTCGg4?= =?us-ascii?Q?SBnSXQ8jDbNz1cNyrdFr33b16kpp+XJQ9qAlVvWhCtlwuEP6g19GHoYrhiC3?= =?us-ascii?Q?tt675Chy5QpiX1aD0td+gw3fzOsWMo1ujlZM5xnr191YeZ9HeCDw8YqHzqyN?= =?us-ascii?Q?JejCriKBTWPWWE63kH84tdG/M9n7gRiPg5vjRhX3USmjaaTIQGUXk660/Max?= =?us-ascii?Q?PZKBczvpLEtlXDmfapNHXoZn0u0ocaG2nG5UlRXA2fJr?= Content-Type: text/plain; charset="us-ascii" Content-ID: <5E52F22CEF55EB449BF6CF9862311B9A@prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable 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 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR01MB8450.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: acb0aafe-0653-4c80-e630-08dbec1df346 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2023 12:15:58.2265 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JwC25sYT+F+IeCD1ud6X1iIprJpM1fvwn5NoW2+hpTzOq3+DixLorFw5R4A826/8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR01MB8553 X-OriginatorOrg: mit.edu X-Spamd-Result: default: False [-5.79 / 15.00]; DWL_DNSWL_LOW(-1.00)[mit.edu:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DMARC_POLICY_ALLOW(-0.50)[mit.edu,none]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; RCVD_IN_DNSWL_MED(-0.20)[18.9.28.15:from]; R_DKIM_ALLOW(-0.20)[mit.edu:s=outgoing]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[18.7.73.15:received]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[mit.edu:+]; FROM_EQ_ENVFROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[104.47.55.169:received]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4SbcXQ6m6rz3K25 X-Spamd-Bar: ----- Before submitting this as a bug, I want to know which component is at fault= . I upgraded my armv8 host and armv7 jail to 14.0. Using poudriere to build armv7 packages, ruby33 fails: making encs Generating RDoc documentation ld-elf.so.1: /usr/local/lib/libunwind.so.8: Undefined symbol "__aeabi_u= idivmod" *** Error code 1 I confirmed that libunwind.so does have a dynamic dependency on __aeabi_uidivmod. That function is defined in /usr/lib/libgcc.a as a wrapper around __udivmodsi4 in the same library. It is not defined in /lib/libgcc_s.so. Linking something against libgcc.a would fix this. The _aeabi_ family of functions, as far as I can tell, is only used with -target arm-none-eabi and not with the default target. Using better compiler flags would also fix this. So... Is this a bug in base: libgcc.so lacks or does not export __aeabi_uidivmod? Is this a bug in base: the compiler does not link libgcc.a? Is this a bug in devel/libtool: libtool does not link libgcc.a? Is this a bug in devel/libunwind? Is this a bug in lang/ruby33? Is this a bug in some unknown component compiled for EABI instead of FreeBS= D? From nobody Thu Nov 23 12:24:16 2023 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 4Sbck76lKCz528w3 for ; Thu, 23 Nov 2023 12:24:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (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 4Sbck74DB6z3LFD for ; Thu, 23 Nov 2023 12:24:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1700742269; bh=U2dtMSFEgXJXmnn2Q9xQMt2cllJb1rTDN48RwkNac2g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jyIatYLHjZJd9Ts5dkPsv9qo2pusgcUEJXehKq4J/7TSuImARiSNM4ZHm+xDsd9OmyS7crYm5WwxKgPLmOVILv6U9oWiZ3n2DaFDy8ZdGwDycsKQChTStSzSrcsOWsNANINhtLybeA2uNDtDf/X5KvrhWqfYzn1KT/zwvSjRyATdmvYZ6XxbgUHSux7BaMsqLB2h5jGoUAxJDfyqu8veqF8xkAUVE3Cyp1gSBZOgaKoMsxiuJwzwHvBG/9xuKTPvW5fJE+hM1rFfnOH5rAzzLx8MyzXtx0ckamZfXq1ztJjXDPN4WDDiS9xqV2FcTxTdR+tPiqY3uD7TXNYpi7OLHA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1700742269; bh=zWwDBh76jbR1GZspWv4v+R4jWnhqSzvoLoWKfHjrdhF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gmyNepFYjp63kZNohie9+nwqZgvQdZnF85/wOYO9xn42Jgiy31cNh8iRm0SXkefOG3kbIAHFtX/xGi5Vd6RxVSw7w+3swUcFG4oWMk8zuoUZsZQVCPVXUv+P7R9/JJ7rnNX2U06xgboh2YUrKnfW24dK2OdHGktUMON9/4Ua8ZmKEejyMLIB5uwFP89muSpG9qEUttaJ+QsvKhJISO2eEAtx+SJdy9Apa3gwdnLgmqbmBOf88gapKuPekQSWTWqr70+wWIiGo9f4zerhGdmAEXByY8Z2G6lFR2nxtUZWJC+PN9EWWpY9O+frzeec6jB/HdmtlTJAZLbJJyJD22QgSA== X-YMail-OSG: 0aAXBEQVM1lg2BFv.itxNIXigw8ruuLrivqKhLEMH_Vo_pIdqEf3Q64dMIbmQxC kl5hwFuN8aTYbyr68q4L.WfyJalk_8DOPntyUVIlYg.X6gOl.5NJBi3hh6HkbLtfYjmbxX1bX06m Rddv.Gn99XJGPr9LqNPI6VFvlhGWCVR5lUNBIRwNWyN3k_58x2GnoMKcfKVf_R9tklzkRDzSSgpS loqy1e0.f97RZOMkPH6b_7ec1Tr36K8BBmUbTxNogH6jEavajXOY.F0ds_GRrY8mA4Aw_JRp0wN2 aQ.bFwBpvW236ggY1ULEBb4eUC7f3rt1FU2Uj8.VWgmpoq4NT74W3mwJonSc9wBNxuH.9hRUNK.R mVdgtE1JQkni4NIjLbWmluD5pkJckMasqkavwGu4zIMxfw2ylj0RxyEoW3.nrK_xu31HFPmBUGlT 3IBnxurLkoEDjTFEzWZKCz8x4iV64zHNa_a2ma5qlKhrw5kYz2dHybF_G.ljRxNylDuC57FDGk3v 2f9mqpbePGUUZgZAEUiha8YYsUA5pG0Xx1MidJ1WnkqeQA5rIdmxj.MQUQVwfonUP6h3xAUL79np _iXhJAZt7Xnc40uJT8KvQv10h0Ee_pMdrZloJ4U0AB_N66SRKFFkRkMzM8eyUMa5eF00QzrATQzF vU1IVkcG9P0RScksbrVO82A_Sc6dbLaPJGuM7Xa3pINYeowKSwuKVUL08QJ1Ppc__lugOpnnC_00 SfbKcL.pD_jeMSgkgu7cfv13_w1nn.cCzTkGsYEkDNpcwZTO1X_kvB80qu3zeGH6JfslRX4k9.Mz n7m0gOWDJS4r8O36qFFFi9hEQ4TmIDcduYWhqefETrbZBaMemX5Be42M4LtlhW0gzyusRO.TBcL9 eiy8Ocl63XRMqrEPe3dTQ5UH8eA7yt0bVTWQ3tc5CBWYtUasbdq9G.WFpkhchqW6rThBAGedy0oe FEsPFSHWDQpPWqtSeKiCa0Bcly6gnYomTNSzDR6CnjT_JjxPwfhKD3SfnC4LjnRiAmJYIBRBNCXa MOsl7OlFVItej5tr564vMzdjBDue1t8WvVLJ8kAyJ7QbOUOma7xamiNBtMX6zM0BYTj3C7Tx_ZlC q3AxhnPvFNRO2FaRNybdXM2VB5oDDtXb68i3xB9A516a__kU5vXOOh9Gkkil8GrN9htk33H3vmrY j2.qVkzJ1GJinJ8ANlWZaU_SGGSbOH0JjrSyaTH0JMG_JbSqgwNXqq2eWd76jjXnhUdKIAiMLn_Z aMIWJbOKGrXQfBxzMpwDYvOVK6GptLEEXZyLQBabd9oOuK3O_lLh3JhSuLJduZhaSJvYASmivKiW Nb6na68uGIwJ51kIHpA6gv3EjQl1GFQ.sNd.tbK2_4D3QNae_Uq_619OXaLNZ8NESZMTq5a..AAq EKNTXzz.R8ixZe.Ifubk7KjE.6fCNargJchdrmjZgWJ.MC.Ykk6xJxMMoSGUXVrT31N41i9D_eu1 VRJiXdVh5GO.ixfBTvyoLHYouijDNemdpt55qY.dJ53xSHp7SETS3PrAuZvxPXcOr3eFqgKpPs5Z T22fo328Vnd1taxOeTyz1ovmPYA34Gx5EBIVLZ.us01XaO9ziQwb2kupsjzziZd70xPguZhPmxZ3 kSL.xqkNvQ5BDGZXYahYkw0s_TnbSfUj37URves0oT93oIxrO5TAhbJS5JWITj9RBF9a4fpoD1av TnrR.BoW5lcMAi2ya8c49vT3RWbpUt3dgg4PHgM9OTLRWri8ehR1Okg72o2exXRosJhxGSQ_fERx DkEsJe4T0RMBSdnc6hFN0fVI_3N6Czx1LFrrb7ex6l0hNIDf38IfCppKoEhPvRFu4kuekg.jLlzx JEwlSr6V74CSaq6MuPtrPLmYoFR_iVF52Gi8ExcZru.i5.WWGTkerLWrYAv6QMnWn0D97N6S9G68 wsZQY6BqhPi20Ov62BgsxfDLG7BfEWMA70yqyjyi5wihMgACP4jFAFD95stT_pqPP5.UJXURFK4g C59oAYPLvA3I1JlXOLIh9RD.0EVG1rU_AWs9iGXF1kXPjLUxjqpnX85xpoYb6XP8.eep85B9vePo __2XUJ4XvaMc_K1xf6bSHzjKOULSN6.ZVY0MbIsaQSGx7EQJqbWERVFj5Rb8VBOGl8eobUZA_TWo Owe4f0u8EPrlHyamhSS74.nUktJqxoIUNfAAyYwSSAvwCwva0okT0G7SCuNTsVZDdqfoKl95B_kS K232JhcY3iwLWyPFNL8qGkt0I61xqm2dhzil7w9l.KCqFviWkX6pAOlO3hWtFmNGwbSw4qkZcYCU - X-Sonic-MF: X-Sonic-ID: b6e043c0-d088-49db-ab32-3292ad25c1c3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Nov 2023 12:24:29 +0000 Received: by hermes--production-gq1-6775bfb8fc-nhc8v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e01f6472ebab52676c7b3f5afa68b277; Thu, 23 Nov 2023 12:24:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: Undefined __aeabi_uidivmod in 14.0 armv7 From: Mark Millard In-Reply-To: <0EBEB2B6-198D-47C5-8715-02F19EF5ED06@mit.edu> Date: Thu, 23 Nov 2023 04:24:16 -0800 Cc: FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: <0A4098ED-2084-4F9B-8006-7832E8333CAC@yahoo.com> References: <0EBEB2B6-198D-47C5-8715-02F19EF5ED06@mit.edu> To: John F Carr X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4Sbck74DB6z3LFD On Nov 23, 2023, at 04:15, John F Carr wrote: > Before submitting this as a bug, I want to know which component is at = fault. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271087 > I upgraded my armv8 host and armv7 jail to 14.0. Using poudriere to = build > armv7 packages, ruby33 fails: >=20 > making encs > Generating RDoc documentation > ld-elf.so.1: /usr/local/lib/libunwind.so.8: Undefined symbol = "__aeabi_uidivmod" > *** Error code 1 >=20 > I confirmed that libunwind.so does have a dynamic dependency > on __aeabi_uidivmod. That function is defined in /usr/lib/libgcc.a > as a wrapper around __udivmodsi4 in the same library. It is > not defined in /lib/libgcc_s.so. >=20 > Linking something against libgcc.a would fix this. >=20 > The _aeabi_ family of functions, as far as I can tell, is only used > with -target arm-none-eabi and not with the default target. Using > better compiler flags would also fix this. >=20 > So... >=20 > Is this a bug in base: libgcc.so lacks or does not export = __aeabi_uidivmod? > Is this a bug in base: the compiler does not link libgcc.a? > Is this a bug in devel/libtool: libtool does not link libgcc.a? > Is this a bug in devel/libunwind? > Is this a bug in lang/ruby33? > Is this a bug in some unknown component compiled for EABI instead of = FreeBSD? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Nov 23 18:23:54 2023 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 4Sbmj02Wfqz52JGw for ; Thu, 23 Nov 2023 18:24:04 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "fuz.su", Issuer "fuz.su" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sbmhz6zJpz3NWL for ; Thu, 23 Nov 2023 18:24:03 +0000 (UTC) (envelope-from fuz@fuz.su) Authentication-Results: mx1.freebsd.org; none Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.17.1/8.17.1) with ESMTPS id 3ANINthg013514 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 23 Nov 2023 19:23:55 +0100 (CET) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.17.1/8.17.1/Submit) id 3ANINspX013513; Thu, 23 Nov 2023 19:23:54 +0100 (CET) (envelope-from fuz) Date: Thu, 23 Nov 2023 19:23:54 +0100 From: Robert Clausecker To: John F Carr Cc: FreeBSD ARM List Subject: Re: Undefined __aeabi_uidivmod in 14.0 armv7 Message-ID: References: <0EBEB2B6-198D-47C5-8715-02F19EF5ED06@mit.edu> 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=us-ascii Content-Disposition: inline In-Reply-To: <0EBEB2B6-198D-47C5-8715-02F19EF5ED06@mit.edu> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR] X-Rspamd-Queue-Id: 4Sbmhz6zJpz3NWL Hi John, This is a long standing open issue in base. These __aeabi symbols are shims used by the ARM EABI to implement functionality missing in the instruction set. Back when this was implemented, whoever did the port hacked something up and only added those symbols that were initially needed. However, turns out a bunch more will be used by gcc/clang under certain circumstances. While we actually have code for all of these symbols in clang's runtime, the version scripts were never fixed and the symbols remain unexposed. I have previously raised this issue with a bunch of people involved in the ARM bits of FreeBSD but never managed to get anybody to fix it. Maybe it'll be different this time. If you want to give it a try yourself, check the ARM EABI document. It has a list of all __aeabi symbols that should be present. You could try and add the missing ones to the appropriate libraries. Yours, Robert Clausecker Am Thu, Nov 23, 2023 at 12:15:58PM +0000 schrieb John F Carr: > Before submitting this as a bug, I want to know which component is at fault. > > I upgraded my armv8 host and armv7 jail to 14.0. Using poudriere to build > armv7 packages, ruby33 fails: > > making encs > Generating RDoc documentation > ld-elf.so.1: /usr/local/lib/libunwind.so.8: Undefined symbol "__aeabi_uidivmod" > *** Error code 1 > > I confirmed that libunwind.so does have a dynamic dependency > on __aeabi_uidivmod. That function is defined in /usr/lib/libgcc.a > as a wrapper around __udivmodsi4 in the same library. It is > not defined in /lib/libgcc_s.so. > > Linking something against libgcc.a would fix this. > > The _aeabi_ family of functions, as far as I can tell, is only used > with -target arm-none-eabi and not with the default target. Using > better compiler flags would also fix this. > > So... > > Is this a bug in base: libgcc.so lacks or does not export __aeabi_uidivmod? > Is this a bug in base: the compiler does not link libgcc.a? > Is this a bug in devel/libtool: libtool does not link libgcc.a? > Is this a bug in devel/libunwind? > Is this a bug in lang/ruby33? > Is this a bug in some unknown component compiled for EABI instead of FreeBSD? > > > > -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From nobody Thu Nov 23 22:59:13 2023 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 4Sbtpj4Pd0z52LvL for ; Thu, 23 Nov 2023 22:59:25 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sbtpj3xH6z4fGV for ; Thu, 23 Nov 2023 22:59:25 +0000 (UTC) (envelope-from jfc@mit.edu) Authentication-Results: mx1.freebsd.org; none Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id 3ANMxGVJ013764; Thu, 23 Nov 2023 17:59:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1700780363; bh=Qfiewk2gQ2iNK81yH2PVfrAmXe73DjzgZRE5cCcH+9g=; h=From:Subject:Date:Message-ID:Content-Type:MIME-Version; b=JcVMEnJQR/M+Ia6qgFLZMcssmnCKcBwdqyiVdI6UQ7+sThacqjynzZLiKI560LZUA RuidzsljAyQbys1uz/FWdZmCNpTamfHkcvjxnXSVRzuUepYziH9acQX2EQs6j/O5se kQxnmjj5OOVfccdR7fWYoaZjp/H1QrPvOLsNn0CJ93KxA3rz4NcB7yrwul/dDfHKbD veamGqFWP6/cPB5IpuNHOBdg7h29s5PHT4MGCW/wVWhBfb1Zox+KxzlJsrqbFa4UNc BAgYh7z57l/0kkuX7nxNwtPCvlx0/SeVTMNMVLW1NKFPcXkweIb6gmgG07jenrpDFt WmFlwknU+EhFA== Received: from oc11exhyb4.exchange.mit.edu (18.9.1.100) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Thu, 23 Nov 2023 17:58:58 -0500 Received: from oc11exhyb5.exchange.mit.edu (18.9.1.110) by oc11exhyb4.exchange.mit.edu (18.9.1.100) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Thu, 23 Nov 2023 17:59:16 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.169) by oc11exhyb5.exchange.mit.edu (18.9.1.110) with Microsoft SMTP Server (TLS) id 15.0.1497.48 via Frontend Transport; Thu, 23 Nov 2023 17:59:16 -0500 Received: from SA3PR01MB8450.prod.exchangelabs.com (2603:10b6:806:382::17) by LV2PR01MB7837.prod.exchangelabs.com (2603:10b6:408:171::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7025.20; Thu, 23 Nov 2023 22:59:14 +0000 Received: from SA3PR01MB8450.prod.exchangelabs.com ([fe80::79a2:b3b5:bcdf:bdf0]) by SA3PR01MB8450.prod.exchangelabs.com ([fe80::79a2:b3b5:bcdf:bdf0%7]) with mapi id 15.20.7025.020; Thu, 23 Nov 2023 22:59:14 +0000 From: "John F Carr" To: Robert Clausecker CC: FreeBSD ARM List Subject: Re: Undefined __aeabi_uidivmod in 14.0 armv7 Thread-Topic: Undefined __aeabi_uidivmod in 14.0 armv7 Thread-Index: AQHaHgbQOZZaQlbMD0SVShQUbRvzu7CIOGAAgABM4IA= Date: Thu, 23 Nov 2023 22:59:13 +0000 Message-ID: <314390AE-09B7-49FD-AB0C-256A8786F043@mit.edu> References: <0EBEB2B6-198D-47C5-8715-02F19EF5ED06@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SA3PR01MB8450:EE_|LV2PR01MB7837:EE_ x-ms-office365-filtering-correlation-id: 58255411-8374-4bad-b40d-08dbec77d007 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fha5h8ecOuC7IkIHo+9PEXXXhNNdo1Cz9Ns7s8B9y3+4bz+KruI6+LHw5dOWdVTw0ICtk4ZIrAIRjYsKj8gk/pa86EKLU7KOC54LY6y10+XuaQJMdLwzLe9FyC3o0iD53sja/LZo6FB5E+JdaZKsP+5ryp1t5Dq5P8mezSg/FjIKi5osA7H8SvDTPKX2rjj0S0aiEEJR7/PueE8P+dQ/M0q/pFJg/Humc4V4dSqxSn/GVAdNdLlz3PrcLwJIpnDaKA9Nhz2t7fSSIjVNKfnycwvhAyjOHqZfe4mb0kV60O5cHjjRmbvHTxjUIJrN9eJCaf9JvhVcIZIV9loIbBYZWrtfIQy/aa6NAU6Knu9i5SPt3tITm19x7QgFdQKJmWO8ArpN6S+Zti3JgvEarhEin0YLmFfqx6wf6L8obznetjtFO8k9MeQOnIoscpeIOk1iWQ2Jo99yLYcWBF4gFDxxYsq+r0XX28Few/6zF1Bv0Dj3buM73jbDOHvlJQwEW3JPbEijh8Wib8JViVfH2TyiP69WYrGewt5FMHkua2mS8mXGuAqaVcuSWks+rUJXNxL2FheH5v28H8dPj7qDd7Jf1QZ/RjoZC/03zgog7y8oJldibebYRQLt+dqSf4NXCUx1 x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR01MB8450.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230031)(39860400002)(376002)(366004)(136003)(396003)(346002)(230922051799003)(64100799003)(186009)(451199024)(1800799012)(6512007)(2616005)(478600001)(71200400001)(6506007)(53546011)(5660300002)(2906002)(76116006)(91956017)(6486002)(41300700001)(8936002)(6916009)(64756008)(8676002)(316002)(786003)(450100002)(66946007)(4326008)(66446008)(66476007)(66556008)(75432002)(122000001)(38100700002)(33656002)(38070700009)(36756003)(86362001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?gOa5pzrfciRYX39/+NhUMwVFyUIgttI6l51AXlRLR4BmBxPRViaYVQ9CD8A/?= =?us-ascii?Q?ZQxnbmaUI8nxxhcjXS4kmao5AuJt3sALF8gxdK/Z7Mk68KbxgZl9btYUu4UG?= =?us-ascii?Q?PWAiBwRBHbBak855vBL8XPEb0cwkQq3yiNlYsb00UB+XV0e1Wu7Z6qBeQF/c?= =?us-ascii?Q?kuFjQqhKnBl0bUGRBaF5edFXFS/vMJIV/Q4cWn+XOz5etE2mCGXxfOmgkarZ?= =?us-ascii?Q?6WvRRTdBWrF6dlPowzkiCG6Gzu7sjUtOHqrsIRBilZwyM6dlEz7iZlSc7XvZ?= =?us-ascii?Q?pA+fA/PVANKhU9MK/Dzwu+G7eHMAjdoFircVQFZwRw32vGtbgcriqBdiI0YC?= =?us-ascii?Q?TFARi6+cNNcYunCYEY/nBNOViY4bEC3YnR41zYzzmauTX/sWerUBnawP4dYQ?= =?us-ascii?Q?qERvGjprd+vH1fCBDz/A8L0kRAoA1ixvb7VBgdpWziv1xJBP4AdN2btFwxNc?= =?us-ascii?Q?eVQymZ+KDjNhvcMPc19Ykizp0bk6wlgkdvgLoMgr1XK2ULdbYiUGM5d69vsu?= =?us-ascii?Q?1+k1h+UFlgB/qeTw5f6hNlv1rT6XW797jj/WVaDm+cKD3YOctOOw99aRVpPk?= =?us-ascii?Q?zjO4PjnbRxgvSNjGIfegIQfg0hCmemYFY/7UYEzt99dT+0NCkzWqoTpQobU/?= =?us-ascii?Q?t9L55juQsr8M2BYUJXyFJ0U1T3GQan7HtFFUeBBilrgmMk84+x5IR6gQRTfu?= =?us-ascii?Q?heSAWR5NQgvK4hwQHD/OuRXENvV5T5f8OlNa6lraqAhX0ILSgZ12Mev1sz/n?= =?us-ascii?Q?RoGIewafCkwnDpURT22RfkQBPLxhTixxzJ6Uy6IGEG2ogkm5KJqrqR1xvD4Y?= =?us-ascii?Q?mWVqNEIcMvb5V9zrB7DjMnXFba0+GRECxvXx97cj12Z1IfZgdiQD/KjXXf2a?= =?us-ascii?Q?hm1HCaS9HPtCthRNMSMmq5r/sR1ve2KCqdNshjg6X6INcI5ia/oBcuPOzsmy?= =?us-ascii?Q?NVDo5zv0X6iV9/kWfoMCHEudkQB+qnRmaxzJuTw28d/2vTaqyyX7ZU2S4FXC?= =?us-ascii?Q?eea11LYRG5vgMwpsWZgZXEazZhxsKShyzjMPPu5F4FlXT6YXO67kp6VE/JMO?= =?us-ascii?Q?foPh57cpv2kQJydypvXiAibFnYXepjUhVLeJTf488OeudTi8Zf/cqdCmAODp?= =?us-ascii?Q?4QIcH26K1X9XticSZQSnkznpRwZO/sOTkqJKnXWRWp/KL/Hmve3ouRBxfnFx?= =?us-ascii?Q?P19y3PguB8daUMv+evCVOuZIFwou2GurPA6g+JPU7CnSVzDIzZtsWCZ66WKS?= =?us-ascii?Q?gMILAThOzWTV5svspE4wrcTXxSnfHOtqyLyebmHhZpdUlvKNIMd8PiGXfo7b?= =?us-ascii?Q?4aWpSz7mmfrsfn7ea9zzHBNKIUi4lO6PrNWMoBXt6lSB9vCvcEY1bCmq8CZW?= =?us-ascii?Q?8btAAwhzbpqegMUercd5IC+IowWIqNzMbBfFBvb6pcErLjFucpBVMpZQAbzD?= =?us-ascii?Q?wFeCP55+xG6xpLlC80udTLdldcdZKMFAgdXOXfsbBjZFXrikjs6DR702A51x?= =?us-ascii?Q?v0uW8AO6OaDrGz2FwmZlcE9utrm6nPtvwkNCWI8V4HMHWqa7UnIAI2GX5Sz6?= =?us-ascii?Q?o2/aGxbC5n4KYjzCmlz7gu7LSr9nczR97+lj/TGOUcJ07utxJG+vC/jDjRJo?= =?us-ascii?Q?z8t3i0E+edkqW/E6ad48flfirDBzfJLHFEf2pWfCBVkW?= Content-Type: text/plain; charset="us-ascii" Content-ID: <86DA7CC404B19442A0546E3E6FCBF580@prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable 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 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR01MB8450.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 58255411-8374-4bad-b40d-08dbec77d007 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2023 22:59:13.7981 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: quSWf1vpUuQ7om+QXzXevOLwOkt2kaF6WrLioDKSQnqRXXQ1uIIFTQlVrVY1IAJJ X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR01MB7837 X-OriginatorOrg: mit.edu X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US] X-Rspamd-Queue-Id: 4Sbtpj3xH6z4fGV On Nov 23, 2023, at 13:23, Robert Clausecker wrote: >=20 > Hi John, >=20 > This is a long standing open issue in base. These __aeabi symbols are > shims used by the ARM EABI to implement functionality missing in the > instruction set. Back when this was implemented, whoever did the port > hacked something up and only added those symbols that were initially > needed. However, turns out a bunch more will be used by gcc/clang > under certain circumstances. >=20 > While we actually have code for all of these symbols in clang's runtime, > the version scripts were never fixed and the symbols remain unexposed. > I have previously raised this issue with a bunch of people involved in > the ARM bits of FreeBSD but never managed to get anybody to fix it. >=20 > Maybe it'll be different this time. >=20 > If you want to give it a try yourself, check the ARM EABI document. It > has a list of all __aeabi symbols that should be present. You could try > and add the missing ones to the appropriate libraries. >=20 > Yours, > Robert Clausecker This solves my build problem. I made up a version string and assumed all the __aeabi_ symbols in libgcc.a were to be exported. I omitted the string functions as suggested in bug 271087. diff --git a/lib/libgcc_s/Versions.def b/lib/libgcc_s/Versions.def index d28e9042f744..b90bc705e3de 100644 --- a/lib/libgcc_s/Versions.def +++ b/lib/libgcc_s/Versions.def @@ -31,3 +31,6 @@ GCC_4.3.0 { =20 GCC_4.6.0 { } GCC_4.3.0; + +EABI_1 { +}; diff --git a/lib/libgcc_s/arm/Symbol.map b/lib/libgcc_s/arm/Symbol.map index 92b54761d810..49b0820b2a73 100644 --- a/lib/libgcc_s/arm/Symbol.map +++ b/lib/libgcc_s/arm/Symbol.map @@ -15,3 +15,30 @@ GCC_3.5 { GCC_4.3.0 { _Unwind_Backtrace; }; + +EABI_1 { + __aeabi_llsl; + __aeabi_lasr; + __aeabi_lcmp; + __aeabi_idiv; + __aeabi_h2f; + __aeabi_d2lz; + __aeabi_f2lz; + __aeabi_d2ulz; + __aeabi_f2ulz; + __aeabi_ui2d; + __aeabi_ui2f; + __aeabi_llsr; + __aeabi_lmul; + __aeabi_d2h; + __aeabi_f2h; + __aeabi_ulcmp; + __aeabi_uidiv; + __aeabi_l2d; + __aeabi_l2f; + __aeabi_ul2d; + __aeabi_ul2f; + __aeabi_idiv0; + __aeabi_ldivmod; + __aeabi_uidivmod; +}; From nobody Fri Nov 24 16:07:48 2023 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 4ScKdK0PhKz52BNn for ; Fri, 24 Nov 2023 16:07:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ScKdJ3ht0z3M6G for ; Fri, 24 Nov 2023 16:07:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700842068; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=o7+kZ9ngN7wwEQR4ju4BcxNTiDaRSU82y5Cv3lJxeIE=; b=tlfPL1WoEZyWzG2t4Mq9uD/SlnMuzP1x90fJTSKGegd9kOJRLSS0A2w0tfP1rKM0TZwep2 8UVl3285wHKd2GlDGxALruqKx1qLnmWZTpqK0G4BoJSq8XbxVK035laXdQclv8pkHwoYmV euCayOhCYzkHNG2K634JVwEfVol79gNm2tP+vuYNg8qn4EqpSvrFnPb8h3m8xGsEXxaeu8 /XFdC0qXi1SmLZJiVfKDyMzyQh+dH6T7yUnu/u9Lo4fAM6nDUNSWZsgU/53rEeuO1bsybv 3FN4W2vPyTiE5Fo7j67tSJzxPMcWTKESTVP2JlXDMDtphbu8yoz2rDPVtpatWw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1700842068; a=rsa-sha256; cv=none; b=is4E3CwuWJjTKzueT1KzCmk2mpZdsHiMZQO1MTpmLfeyRdIdwx5ir1SED2siU/YCgHRFNx g3i1g9/scZul9Hc1ewZcp2bQtwhOFbJE0NV6+IGvk1YXffu+T5O8+yx7bKpZxy/b+d91IN oI+Q0w7EeHHyLzmT1UMVaCkNYic8C6PSomrLovnGN/cG37SdnqfD7xYmFP8+sq/3Kvx0c5 /fmGIbF081atzErzJGQawHSnrybP90qda6dOlZvEVXBhT/LnohhVnUS4M2In/oT/F6mLUf zYiD/PVdtF62ApIVpKvK6FVOEHSG7d5uxtLam0rNMC6hTaxOz1xEvaEGCjx3GA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4ScKdJ2myNzrhg for ; Fri, 24 Nov 2023 16:07:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3AOG7m3l045284 for ; Fri, 24 Nov 2023 16:07:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3AOG7mqh045283 for freebsd-arm@FreeBSD.org; Fri, 24 Nov 2023 16:07:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 274705] unreasonably large stack reservation for armv7 processes on arm64 Date: Fri, 24 Nov 2023 16:07:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markj@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kib@FreeBSD.org X-Bugzilla-Flags: mfc-stable13? mfc-stable14? X-Bugzilla-Changed-Fields: assigned_to resolution bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D274705 Mark Johnston changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-arm@FreeBSD.org |kib@FreeBSD.org Resolution|--- |FIXED Status|Open |Closed CC| |markj@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Nov 24 23:00:34 2023 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 4ScVnz5vF1z52FY2 for ; Fri, 24 Nov 2023 23:00:55 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ScVnz5V1Pz4s9K for ; Fri, 24 Nov 2023 23:00:55 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700866855; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=U5hjzj4IwKOaSixdOkwmvH05EKdaBAfgZDU9blfEKY4=; b=KeFCjxVs3dkPlQQXbut25voDFMi1ETGbGcoBulIMwkldLgkuxMVevO+0a2HIY0poBmEaIZ bSDb6HVyfyWW6BSYgsosLPl9LY4uukrNq/NaE7ffioOmNbkWeqMt0e3RxB/uOetORBMJPc NuETVkqQ3iUvEx4xEKrCNpJ1bu5HJTydiabbLQX2aiIkT/H6dkOiLtLOl6sYddDqBSfhtt fuWKQxfTjfUSGw83Al5+zG7UQWUNUDqmcNWhNVKLFjXzhgOJt/HzjWrAX/pBFpmaZfeUhk fiHC4MO3MJ90/BlW0p28N0oMmfB4F0JC7e59jiZm9SIG4eoKrHS/T6KbgUuVDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700866855; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=U5hjzj4IwKOaSixdOkwmvH05EKdaBAfgZDU9blfEKY4=; b=bAy+Y/UYmBDZDArr6kVvbToTq5KHJzcEJT9Bv3JCTwl7LAbrVVoeFIJQJ4awnV0xPKlqRC dq9kuXLF9SKUY2FfXLD4PzV+/0uk1iGeN+ephEc8b8M6/i91lW4G8WjuhjVS2a3mTKGN1a Md1G0s608q/5dCmcIpRVHguXzjhHv6BRAHblnwtz9x6bzy5wDRsinnWUdOImmeqwmqfdfv 8YaFOBW+TN6lRpvA7XEPJabwdCwKATvH3rL4EtForxkc27Z1P322H9rZJBDsw69WypGu6X +Tlv8EKQZ60uZ8oQDke2bJeyjaaKvcN0SuLn3o1RCueWCqfPVUObU9nAB9SSSg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1700866855; a=rsa-sha256; cv=none; b=aPI4UCjbXyo7yzzHXRxTK6J5DGaMtjAAcyjIE/jWUBhBppkmgeputLbhUvOP9lQZBWsmvg /978ys6yzTk5VO013ZMXgXuwcVSBeTuCfJFtF3l/mKSdEBRw8PIU9eKV8a3gFFtKyvEWaN AkOKaamWJ0IyBDS4Sdy8ZbCBI29ooja8Dum6sksKRk/zHWWLE0jRmcX/pNql2ym1tgyQS1 r2IZ/cplZBJA9ENBn51cAy2hVNq7bEY2B/Sq7NskJRSKP+BQcGv5HvlvgpqT4H8uaK9YFv KswIKuLS8VQ4ufvrxu1t99ii0o+RLquwrO7EowRBeUIygTKAip2PNh7B14qzuA== Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202]) (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) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ScVnz2tqjz9M0 for ; Fri, 24 Nov 2023 23:00:55 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: <9518dc38-e44b-42ae-bf87-6039ac278ac8@FreeBSD.org> Date: Sat, 25 Nov 2023 00:00:34 +0100 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 User-Agent: Mozilla Thunderbird To: FreeBSD ARM List Content-Language: en-US From: Jesper Schmitz Mouridsen Subject: firefox broken on arm64 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Tabs crashes with signal 4 on arm64 not firefox 115 esr but librewolf 117 dies as well as firefox 119 and 120. Hve not tested 116. example https://gist.github.com/jsm222/e6199a03142f5716921c82c3d2f3ddc5 /Jsm From nobody Sat Nov 25 10:33:43 2023 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 4Scp9c0ZNbz51dkW for ; Sat, 25 Nov 2023 10:33:56 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Scp9c086qz3cDb; Sat, 25 Nov 2023 10:33:56 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700908436; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KL2jWrXjhG/8XiSFNGSPiPkYlAEnjo+ZVW05mUxOAcQ=; b=QqeFYKdebEqIXlKRoZnOsYTy9ZMkAZ3LaZwBROvTwM+N+uH3mnoCb3fh8gldbc9a0dkUl8 GV6EnMiBc6vjXoDexMmgmvo7120TyJnh4G7h/akw2AzuWlIeh4FINVwUhlFXJpC8WRhBr1 SHtj1cbzrS5c1e/Md6hCbPuuIbbJFwb0Ix9nU61dFqhrx85dY0RbWYKtduud6ZMr4fxo3v 1p39e2q5DSu3BogpmTZ00Vnc5HrsHJxXfekWDHea0L+dXj9lTKSLWnU9PNlJqTy+aMzeWW jwkJl0iwCoCJvivn5TFrjf8i3TbRJDmVH7l5tVbUVnAOa10AskR4wfpPqNSBsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700908436; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KL2jWrXjhG/8XiSFNGSPiPkYlAEnjo+ZVW05mUxOAcQ=; b=kTDW3OkQchq+Gfh4xqNLPZ3JbU19m3xpNWyzFyYD2wwqKb3Y7QcekUr3K1B9Ul5H8gN5RM 49+7cYn57sKSde6HSUC2e2w1PBt1Sz0+dlcKMJ2BUIsU7G2x3Bal/Ox/muhEKjyohpKt0r hcKKYa/A35vXsl7gzR9F2/0wBJh1gmId8zMDQTXDfGVwUq1hlsScqmvQXkFJthdMwTyQWQ Kgx11CR09J6NvUrWyghll+5ht5sUIENUzziPfrRHSi0wq/RZf3YVfwN9gbJnE0goiGvQou 4Uiq+ZnbVpnn7flMudnD8y3qFcVrqLI119kmCch8GhqFy58hR3Oft5hBzxnBXg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1700908436; a=rsa-sha256; cv=none; b=w5zPp7f6EGF0PKZHdYcsXVqwoKoR+MpiPJ8B+GpF9Srdzc2rGivcAarL6dZaiFamdXaSKE o625qoxOebEyROe3I8x+gm+ah2udHffkWDqUZH4vHbPjxFcbSzIY0buSqndY5iSYu11XM2 pmCPsxMv+ivNNGh9LUmt64HVY2Cix91lI6Tb/vaIvzpa9RvBBTWWP70GJvUTehDTQbL45z pCueYmbLp/w8YYh9o/4R6DmcQid4Oa/2qPXqCHhf6owq+riqpCKMXl6ClQv0cT7LxxsIWt LAqopinUaKl0lM+baeGOnVhmED0Ku1B0XXEeb1aXGyL1HLuMw3YZYwMo0rbz0A== Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Scp9b6DDTzrWD; Sat, 25 Nov 2023 10:33:55 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-4239f5c1ec2so5438321cf.0; Sat, 25 Nov 2023 02:33:55 -0800 (PST) X-Gm-Message-State: AOJu0YxC4MvCqTR59+b8vhapob/uW1wVTaIpWOePEX8vuJ/BZLxMTkZB WFG9ZWZD+VrUxL52DcHG9lqdTsNnt6tunOi2/H0= X-Google-Smtp-Source: AGHT+IEazIbVt3Cu/Xmk/NQniuIsDVaNi6Oxtr5NRGVqwMTJ9nJg1Ti09q1KW3vwl3Jc1tZWPtWTl1+j/2/6ztxKua0= X-Received: by 2002:ac8:5b88:0:b0:41c:baf5:b500 with SMTP id a8-20020ac85b88000000b0041cbaf5b500mr8365089qta.47.1700908434892; Sat, 25 Nov 2023 02:33:54 -0800 (PST) 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 References: <9518dc38-e44b-42ae-bf87-6039ac278ac8@FreeBSD.org> In-Reply-To: <9518dc38-e44b-42ae-bf87-6039ac278ac8@FreeBSD.org> From: Nuno Teixeira Date: Sat, 25 Nov 2023 10:33:43 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: firefox broken on arm64 To: Jesper Schmitz Mouridsen Cc: FreeBSD ARM List Content-Type: multipart/alternative; boundary="0000000000000eadc2060af79b1f" --0000000000000eadc2060af79b1f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, It was a time when firefox run with aslr disabled. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271081 Jesper Schmitz Mouridsen escreveu no dia sexta, 24/11/2023 =C3=A0(s) 23:01: > Hi > > Tabs crashes with signal 4 on arm64 not firefox 115 esr but librewolf > 117 dies as well as firefox 119 and 120. Hve not tested 116. > example https://gist.github.com/jsm222/e6199a03142f5716921c82c3d2f3ddc5 > > /Jsm > > > --=20 Nuno Teixeira FreeBSD Committer (ports) --0000000000000eadc2060af79b1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

It was a time when fi= refox run with aslr disabled.

Jesper Schmitz Mouridsen <jsm@freebsd.org> escreveu no dia sexta, 24/11/202= 3 =C3=A0(s) 23:01:
Hi

Tabs crashes with signal 4 on arm64 not firefox 115 esr but librewolf
117 dies as well as firefox 119 and 120. Hve not tested 116.
example https://gist.github.com/jsm22= 2/e6199a03142f5716921c82c3d2f3ddc5

/Jsm




--
Nuno Teixeira
FreeBSD Committ= er (ports)
--0000000000000eadc2060af79b1f-- From nobody Sat Nov 25 11:41:03 2023 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 4Scqgp4tp8z52FHM; Sat, 25 Nov 2023 11:41:42 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Scqgn5Cnzz4Vnh; Sat, 25 Nov 2023 11:41:41 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=hoiORWyH; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-548f0b7ab11so3744841a12.1; Sat, 25 Nov 2023 03:41:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700912500; x=1701517300; darn=freebsd.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=azjIXGhUpx8mRf9YywHFybitCenT4RIf9yxVGY4Q2P0=; b=hoiORWyHZ5ZxPXQkm9pn65hjiDLuv7C/MJ+Vxz5xypdrXDMwnzlV8JWaI53IszeI+x sJDEygaYXlOkCGV/PCWqekyH627QP09CegAcO9Fc1Mxqp781bWofyG43JTwTUyoEAqDr iUnRBD0uOuopLKrfNdJonaBS8MtKD4p3NaBqvS7BjiFKDYAXZJTmMy4HOFCG+6jtbJIT qSOQGpn9Mo/Xk/yIV6i/d1853ykmlW0fHsQPbO+M8+fRvpKFXV8Bsm3NWnbMcb50kTcj 5L/IgqnD6wN1Ksx4HkARTgp+HCsPA7dHA1Q2xJVZUxbvY9H1NtHAOxNi6fRZ/iExKBQc goTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700912500; x=1701517300; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=azjIXGhUpx8mRf9YywHFybitCenT4RIf9yxVGY4Q2P0=; b=vW1Is14FHhJjV0zzIrmZvrhJ11v5iETF1ImEnukYrtwYoDKjJJ7UToOeRfHBLqhFT2 ANl4vj8X+RHgBcvoiwfbJtJR53NTOE1wSc12MpMZaIhZJnQujozrGqpi82Tt4glIe/ov qpk+K5VdlXjQXDqY86kIkfjg0K8oK/hO87Dk+AYv3ZPZBSJBKSY7JZWstRInkhgeLsWL T5q4uLuPsNULsFKjC4V4wZf+xPf1QCEcvogWl4VPnV3uqflR+qxhbRCOLqVkmJygHIbN Q9Q/ulFue3MBCXgJG263suEISC2K8X98l4h9IKSz9WPytRrh9CNI60Y+W8/Uxru6LaVA iuqw== X-Gm-Message-State: AOJu0YzO05HLZ5j3VJQfFJZVZoGmeHBUQse1MK6iXGWzzXWvR+4THN30 v0VuaTWrFjJldNB0EGVQDbe5cUMif6pn7zNx+SeVVh1eTvo= X-Google-Smtp-Source: AGHT+IGpCIUAyjFh3G2HUz4/okVYKzia3wH/NAaFC75uH5L3c2mUsSVPHkOyuVI0/FhJpw74VS3WFG/LcW4W1pbsWhA= X-Received: by 2002:a17:906:15d:b0:a0b:6d32:2e09 with SMTP id 29-20020a170906015d00b00a0b6d322e09mr1386684ejh.36.1700912499758; Sat, 25 Nov 2023 03:41:39 -0800 (PST) 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 References: In-Reply-To: From: Mario Marietto Date: Sat, 25 Nov 2023 12:41:03 +0100 Message-ID: Subject: Fwd: Should we boot the FreeBSD kernel in ELF format or in zImage format ? How? To: freebsd-hackers , freebsd-arm@freebsd.org, FreeBSD Current , FreeBSD Mailing List , freebsd-xen@freebsd.org, royger@freebsd.org Content-Type: multipart/alternative; boundary="00000000000057995f060af88d0b" X-Spamd-Result: default: False [-2.48 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.995]; NEURAL_HAM_LONG(-0.85)[-0.854]; NEURAL_HAM_MEDIUM(-0.63)[-0.626]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::534:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-arm@freebsd.org,freebsd-current@freebsd.org,freebsd-questions@freebsd.org,freebsd-xen@freebsd.org]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4Scqgn5Cnzz4Vnh X-Spamd-Bar: -- --00000000000057995f060af88d0b Content-Type: text/plain; charset="UTF-8" Hello to everyone. we have just virtualized Debian 12 on our arm (32 bit) Chromebook. As host / dom0 we have chosen Devuan 5,and for guest / domU,Debian 12. It works great. But our goal is different. We want to virtualize FreeBSD as domU. Can we have a working Xen PV network driver for a FreeBSD arm guest ?. I found that Julien Grall has ported the Xen drivers to FreeBSD on arm. I would like to know if Julien's work was accepted upstream by FreeBSD, in which case FreeBSD as a Xen guest on arm should work if we enable the Xen PV drivers in the FreeBSD on arm kernel. If Julien's work was not accepted upstream by FreeBSD, we will have to find his patches and apply them ourselves to the FreeBSD on arm kernel. We found these slides : https://events.static.linuxfound.org/sites/events/files/slides/Porting%20FreeBSD%20on%20Xen%20on%20ARM%20.pdf Slide 13 refers to a XENHVM FreeBSD on arm kernel config - that is what we want to find. It looks like when that slide presentation was written, there were some limitations on FreeBSD Xen guests. For example, for our debian bookworm guest, I am using vcpus = '2' to match the number of real cpus on our Chromebook, but slide 13 mentions support for only 1 VCPU with a FreeBSD guest, so I will need to change that vcpus = '1' in the FreeBSD guest config unless support for 2 or more vcpus was added later, which is possible because that slide presentation is 9 years old. Here is where I would expect to find the XENHVM FreeBSD on arm kernel config file: https://cgit.freebsd.org/src/tree/sys/arm/conf But it is not there unless I am not understanding something correctly. For now, unfortunately conclude that the support for Xen on arm that Julien Grall mentioned in that slide presentation 9 years ago was never added to the official FreeBSD source code. I am searching the web now to see if the patches that Julien Grall wrote are still posted somewhere online. If we cannot find them, we can ask here and on the xen-users mailing list. Julien regularly reads that list and responds to question about Xen on arm, so I think he will tell us how to find the patches if we cannot find them online. According to this page from the FreeBSD wiki: https://wiki.freebsd.org/Xen I think FreeBSD only supports Xen on x86, not arm. So this is going to be a bit of a challenge to get a Xen FreeBSD guest on arm working. We know Julien Grall has some patches that made it work in the past ! I found a slightly newer slide presentation by Julien here: https://www.slideshare.net/xen_com_mgr/bsdcan-2015-how-to-port-your-bsd It is about the same, but it mentions the GENERIC FreeBSD kernel supports Xen on arm64, but still says we need the XENHVM FreeBSD config for Xen on arm 32 bit, which I haven't found online yet. Please,take a look at this output of the linux kernel that can boot on Xen, and the FreeBSD kernel that cannot : % file zImage-6.1.59-stb-xen-cbe+ zImage-6.1.59-stb-xen-cbe+: Linux kernel ARM boot executable zImage (little-endian) % file FREEBSD-XENVIRT FREEBSD-XENVIRT: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /red/herring, for FreeBSD 11.0 (1100048), not stripped The FreeBSD kernel that won't boot is in ELF format but the Linux kernel that does boot is in zImage format. I spent time reading the docs on xenbits.xenproject.org, and according to those docs Xen on arm only knows how to boot a kernel in the zImage format, so the FreeBSD kernel is in a format that modern Xen incorrectly detects as an x86 kernel. I also watched Julien Grall's 30 minute video presentation of his work to boot FreeBSD/arm on Xen at FOSDEM 2014 here : https://archive.fosdem.org/2014/schedule/event/freebsd_xen_arm/ In that video, and in other places, Julien mentions that the boot ABI for FreeBSD/arm on Xen was not yet developed and he was getting occasional crashes and needed to investigate the problem. He mentioned the zImage ABI that Linux uses, but pointed out FreeBSD does not use that format, and back then it was an open question which format to use to boot FreeBSD/arm on Xen. Unfortunately, nine years later, the only supported format is still the zImage format that Linux uses. It looks like Julien's work back then was using an ELF binary to boot FreeBSD/arm on Xen instead of the supported zImage format that Linux uses and the modern Xen toolstack exits with an error when trying to boot the FreeBSD ELF formatted binary that Julien's patch creates. So the best solution would be to try to port the rules to build a FreeBSD kernel in the zImage format instead of the ELF format. I have been studying the Makefiles in Linux to see how Linux builds the Linux arm kernel in the zImage format, but it is not trivial to understand. -- Mario. --00000000000057995f060af88d0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello to every= one.

we have just virtualized Debian 12 on our arm (32 bit) Chr= omebook. As host / dom0 we have chosen Devuan 5,and for guest / domU,Debian 12. It=20 works great. But our goal is different. We want to virtualize FreeBSD as domU. Can we have a working Xen PV network driver for a FreeBSD arm=20 guest ?. I found that Julien Grall has ported the Xen drivers to FreeBSD on arm. I would like to know if Julien's work was accepted upstream by= =20 FreeBSD, in which case FreeBSD as a Xen guest on arm should work if we=20 enable the Xen PV drivers in the FreeBSD on arm kernel. If Julien's wor= k was not accepted upstream by FreeBSD, we will have to find his patches=20 and apply them ourselves to the FreeBSD on arm kernel.

We found these slides :

https://events.static.linuxfound.org/sites/events/file= s/slides/Porting%20FreeBSD%20on%20Xen%20on%20ARM%20.pdf

Slide 13 refers to a XENHVM FreeBSD on arm kernel config - that is what = we want to find.

It looks like when that slide presentation was written, there were=20 some limitations on FreeBSD Xen guests. For example, for our debian=20 bookworm guest, I am using vcpus =3D '2' to match the number of rea= l cpus=20 on our Chromebook, but slide 13 mentions support for only 1 VCPU with a=20 FreeBSD guest, so I will need to change that vcpus =3D '1' in the F= reeBSD=20 guest config unless support for 2 or more vcpus was added later, which=20 is possible because that slide presentation is 9 years old.

Here is where I would expect to find the XENHVM FreeBSD on arm kernel co= nfig file:

https://cgit.freebsd.org/src/tree/sys/arm/= conf

But it is not there unless I am not understanding something=20 correctly. For now, unfortunately conclude that the support for Xen on=20 arm that Julien Grall mentioned in that slide presentation 9 years ago=20 was never added to the official FreeBSD source code. I am searching the=20 web now to see if the patches that Julien Grall wrote are still posted=20 somewhere online. If we cannot find them, we can ask here and on the=20 xen-users mailing list. Julien regularly reads that list and responds to question about Xen on arm, so I think he will tell us how to find the=20 patches if we cannot find them online.

According to this page from the FreeBSD wiki:

https://wiki.freebsd.org/Xen

I think FreeBSD only supports Xen on x86, not arm. So this is going=20 to be a bit of a challenge to get a Xen FreeBSD guest on arm working. We know Julien Grall has some patches that made it work in the past !

I found a slightly newer slide presentation by Julien here:

https://www.slide= share.net/xen_com_mgr/bsdcan-2015-how-to-port-your-bsd

It is about the same, but it mentions the GENERIC FreeBSD kernel=20 supports Xen on arm64, but still says we need the XENHVM FreeBSD config=20 for Xen on arm 32 bit, which I haven't found online yet.

Please,take a look at this output of the linux kernel that can boot on X= en, and the FreeBSD kernel that cannot :


% file zImage-6.1.59-stb-xen-cbe+
zImage-6.1.59-stb-xen-cbe+: Linux kernel ARM boot executable zImage (little=
-endian)

% file FREEBSD-XENVIRT         =20
FREEBSD-XENVIRT: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dy=
namically linked, interpreter /red/herring, for FreeBSD 11.0 (1100048), not=
 stripped


The FreeBSD kernel that won't boot is in ELF format but t= he Linux kernel that does boot is in zImage format.

I spent time reading the docs on xenbits.xenproject.org, and=20 according to those docs Xen on arm only knows how to boot a kernel in=20 the zImage format, so the FreeBSD kernel is in a format that modern Xen=20 incorrectly detects as an x86 kernel.

I also watched Julien Grall's 30 minute video presentation of his wo= rk to boot FreeBSD/arm on Xen at FOSDEM 2014 here :

https://archive.fosdem.or= g/2014/schedule/event/freebsd_xen_arm/

In that video, and in other places, Julien mentions that the boot ABI for FreeBSD/arm on Xen was not yet developed and he was getting=20 occasional crashes and needed to investigate the problem. He mentioned=20 the zImage ABI that Linux uses, but pointed out FreeBSD does not use=20 that format, and back then it was an open question which format to use=20 to boot FreeBSD/arm on Xen. Unfortunately, nine years later, the only=20 supported format is still the zImage format that Linux uses.

It looks like Julien's work back then was using an ELF binary to boo= t FreeBSD/arm on Xen instead of the supported zImage format that Linux=20 uses and the modern Xen toolstack exits with an error when trying to=20 boot the FreeBSD ELF formatted binary that Julien's patch creates. So= =20 the best solution would be to try to port the rules to build a FreeBSD=20 kernel in the zImage format instead of the ELF format. I have been=20 studying the Makefiles in Linux to see how Linux builds the Linux arm=20 kernel in the zImage format, but it is not trivial to understand.

=
--
M= ario.
--00000000000057995f060af88d0b-- From nobody Sat Nov 25 11:43:13 2023 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 4Scqjk1Tt9z52FhF for ; Sat, 25 Nov 2023 11:43:22 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Scqjj4lGTz4YpH; Sat, 25 Nov 2023 11:43:21 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700912601; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4oezmPnCMdV677tolTKYDl528x8MrmGUXpiOkI88CRY=; b=ruQ0t3ewLft36r1q2DIDH4hC3RNipch4Ak7ruWPUiLl3AO2XywR+pOZc2HdYLPXy6Pi5iq fpaLbWgVD24/Nk20+CXoyyRIvUOhpj0YmRcHcGCTP2iaLN4MFrNOHpgo/mqP5949u7V9Rk iu46g23bgYeyJvCjth6u1JYYrVVr6FHpD9WDhdJSd2IKRs6nq9CBc5XfnJYPqgZp+OrekY rXgBj+gX81MR2d2Q/d/PB1g4aCWPi/R0SpZKkTbEgwetGRpLGRFhh92wDT2aAOXuZVBHoR jGfXk3491sNVxmwI5douu0UBwW5vzHHiZb8hQOqUu9KgDsJk6eFeehChLpw+7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700912601; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4oezmPnCMdV677tolTKYDl528x8MrmGUXpiOkI88CRY=; b=uilxFbsQDvRK/BXhZp4/T1Bnpvr/DEvvIWPljJpw9UM6I+qAMabox8k0LixqJ86SjUXGAC qNI8YVaILVbyzIRLRB7FzXgH1y4OmKWSbXvEVZblq1DkaiOCgDbsd3fbfzLHIv10U1Oz+y NbLCiBLc2LpHJ/Bj6elDiDLuFd1xp1oc8Y4dIK8l9XSSjHHKibHfkrxdFlKsj8sXQlJkft jbURkssop9pTG7hM1eUkb8BvMwxng91/pVbvkD2IULvVLRYHFoEZJmt/iOT4Dgdw973aFU MOCCyT7SatxB9u4c7MW7RQSc7gl1SuMu9d4MV5pFfVQEmFudQ4bG2O38Ge87sg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1700912601; a=rsa-sha256; cv=none; b=xoAH/S+21nE6sf/o6dMbw0/RRPgHYakK6J2BfkRthu/ZmjWVJYm2EGURyAWk+RkXrGKbgn nVtDLKmEJhA+cxTUCIbNswGZT+irqdwtreBS3k7aERWId3ORwL1HGsE1QV1m6Q/XjL4k7B uxaQSIrYBFVIZIGbcdrI2sCY0BLiBZn9IjeMeG+ITgPhp406hjusrn9wApHi1hWDCJQeXx lOsW5A4+jgwhq3c0+BUSdsihWGUDSojYSV3n7gvOFWwZkrjiePDaa+YSm6AKOiHQN+XvJv cn4/9kmkvhfIa/4XjS9RfyHGm7NZOfPI1FjQB9gT+98C8axxnrX2fH/qnu3h6A== Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202]) (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) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Scqjj1J2SzvQq; Sat, 25 Nov 2023 11:43:21 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Content-Type: multipart/alternative; boundary="------------bPc8EBRVq0n0L3d1TnlGtuwO" Message-ID: <53842eff-4c36-4b93-a389-b0257e970e5a@FreeBSD.org> Date: Sat, 25 Nov 2023 12:43:13 +0100 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 User-Agent: Mozilla Thunderbird Subject: Re: firefox broken on arm64 Content-Language: en-US To: Nuno Teixeira Cc: FreeBSD ARM List References: <9518dc38-e44b-42ae-bf87-6039ac278ac8@FreeBSD.org> From: Jesper Schmitz Mouridsen In-Reply-To: This is a multi-part message in MIME format. --------------bPc8EBRVq0n0L3d1TnlGtuwO Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 25.11.2023 11.33, Nuno Teixeira wrote: > Hello, > It was a time when firefox run with aslr disabled. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081 > > Jesper Schmitz Mouridsen escreveu no dia sexta, > 24/11/2023 à(s) 23:01: > > Hi > > Tabs crashes with signal 4 on arm64 not firefox 115 esr but librewolf > 117 dies as well as firefox 119 and 120. Hve not tested 116. > example > https://gist.github.com/jsm222/e6199a03142f5716921c82c3d2f3ddc5 > > /Jsm > > > > > -- > Nuno Teixeira > FreeBSD Committer (ports) Yeah I forgot to mention firefoex-115-esr runs only without aslr, firefox 117 (i.e librewolf) does not run even without aslr. /Jsm --------------bPc8EBRVq0n0L3d1TnlGtuwO Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 25.11.2023 11.33, Nuno Teixeira wrote:
Hello,
It was a time when firefox run with aslr disabled.

Jesper Schmitz Mouridsen <jsm@freebsd.org> escreveu no dia sexta, 24/11/2023 à(s) 23:01:
Hi

Tabs crashes with signal 4 on arm64 not firefox 115 esr but librewolf
117 dies as well as firefox 119 and 120. Hve not tested 116.
example https://gist.github.com/jsm222/e6199a03142f5716921c82c3d2f3ddc5

/Jsm




--
Nuno Teixeira
FreeBSD Committer (ports)

Yeah I forgot to mention firefoex-115-esr runs only without aslr, firefox 117 (i.e librewolf) does not run even without aslr.

/Jsm

--------------bPc8EBRVq0n0L3d1TnlGtuwO-- From nobody Sat Nov 25 17:02:43 2023 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 4ScypR68vCz51jjR for ; Sat, 25 Nov 2023 17:02:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ScypR18H2z3FvW for ; Sat, 25 Nov 2023 17:02:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a0bdf4eeb46so58070366b.3 for ; Sat, 25 Nov 2023 09:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1700931773; x=1701536573; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lJcyYwjFsGDCNUEF2SrPc1fBl800LPaPtK2E4VfkqSk=; b=Em3noFN9pbttYLD3ebSyUU2FmX67+VwjZcNMCmbA+67sOfb4IkdZQINaPY9jAaLvvG CnME70BylLfHioC2TETwbQuCqtJKzQQc5x/W7EuZ1NXwjclKy/dt4Vg0Y5L8DJAj3e2w xeiCNWSOdR0qwRYnz54Z6rEuUNorj/QMXmwNudqsAV5NLwXdz8G0SipvjKTRKONgCAIo tu4CFB4dXTRogK5vNuQBKjA5ZUXO7nS2aBDlvna6q3TmPIS4Tnm5OVZuKNr8UI3mi6Cf SsCuXfcdqL1MgzEcxnGsIDWHDCw/IFE9t8EV7rG1GQS8WXsTBoekDFC7pc6OEzDRq9T3 qwBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700931773; x=1701536573; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lJcyYwjFsGDCNUEF2SrPc1fBl800LPaPtK2E4VfkqSk=; b=m2cxmYdmHQA6nEJrcjvlSevSzeEYDZth3LDAblBNDBfXP4x8K2PKtCBtfLQuMXhXPl qoAWTWzyjF1T66Zb0Cx1Rl+j9dQMaJIcAiXx8p1vARFnxzzkTS/M0Z5gbVIqt7yOCGJt R5EY1cXv1VAjrnr/xfQOf/Ui32BGQMMlgPpp2RyT3tBgTnenhg4oqagJ5uKPKC5A92IT HxEqIYka1CUq3JV41OlhitItlDklb7+pVIrWUD1SxC6ueRJTCByTEknebJ6J0tzScRoS 4o7Qt3bdT/zW8xAzkOtX91vFyvN7d2uXc8K96dvKDr4HbPxCEFSDO7jONpg0CLmgmItA 55fQ== X-Gm-Message-State: AOJu0YyptuzZNqgTODXDPON+eQK2Sq3BVd9JRQQ7NVOffV9fy40Ko1SL HSVLaEH7yGgYrGunL/GphSuHzbeWo7HXd9xMOAwlMQ== X-Google-Smtp-Source: AGHT+IGt9WzvZLY0tUhXeNt9BnWnm2hSaeduHPjx5ve9C1ZRnPuOtAra26+KL+N3o0hRlFoli27UFdGuH6gX0G+ZPys= X-Received: by 2002:a17:906:693:b0:9fc:9b28:7ff7 with SMTP id u19-20020a170906069300b009fc9b287ff7mr5534824ejb.60.1700931773247; Sat, 25 Nov 2023 09:02:53 -0800 (PST) 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 References: In-Reply-To: From: Warner Losh Date: Sat, 25 Nov 2023 10:02:43 -0700 Message-ID: Subject: Re: Should we boot the FreeBSD kernel in ELF format or in zImage format ? How? To: Mario Marietto Cc: freebsd-hackers , freebsd-arm@freebsd.org, FreeBSD Current , FreeBSD Mailing List , freebsd-xen@freebsd.org, royger@freebsd.org Content-Type: multipart/alternative; boundary="00000000000021c269060afd0a2c" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4ScypR18H2z3FvW --00000000000021c269060afd0a2c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 25, 2023 at 4:41=E2=80=AFAM Mario Marietto wrote: > Hello to everyone. > > we have just virtualized Debian 12 on our arm (32 bit) Chromebook. As hos= t > / dom0 we have chosen Devuan 5,and for guest / domU,Debian 12. It works > great. But our goal is different. We want to virtualize FreeBSD as domU. > Can we have a working Xen PV network driver for a FreeBSD arm guest ?. I > found that Julien Grall has ported the Xen drivers to FreeBSD on arm. I > would like to know if Julien's work was accepted upstream by FreeBSD, in > which case FreeBSD as a Xen guest on arm should work if we enable the Xen > PV drivers in the FreeBSD on arm kernel. If Julien's work was not accepte= d > upstream by FreeBSD, we will have to find his patches and apply them > ourselves to the FreeBSD on arm kernel. > > We found these slides : > > > https://events.static.linuxfound.org/sites/events/files/slides/Porting%20= FreeBSD%20on%20Xen%20on%20ARM%20.pdf > > Slide 13 refers to a XENHVM FreeBSD on arm kernel config - that is what w= e > want to find. > > It looks like when that slide presentation was written, there were some > limitations on FreeBSD Xen guests. For example, for our debian bookworm > guest, I am using vcpus =3D '2' to match the number of real cpus on our > Chromebook, but slide 13 mentions support for only 1 VCPU with a FreeBSD > guest, so I will need to change that vcpus =3D '1' in the FreeBSD guest > config unless support for 2 or more vcpus was added later, which is > possible because that slide presentation is 9 years old. > > Here is where I would expect to find the XENHVM FreeBSD on arm kernel > config file: > > https://cgit.freebsd.org/src/tree/sys/arm/conf > > But it is not there unless I am not understanding something correctly. Fo= r > now, unfortunately conclude that the support for Xen on arm that Julien > Grall mentioned in that slide presentation 9 years ago was never added to > the official FreeBSD source code. I am searching the web now to see if th= e > patches that Julien Grall wrote are still posted somewhere online. If we > cannot find them, we can ask here and on the xen-users mailing list. Juli= en > regularly reads that list and responds to question about Xen on arm, so I > think he will tell us how to find the patches if we cannot find them onli= ne. > > According to this page from the FreeBSD wiki: > > https://wiki.freebsd.org/Xen > > I think FreeBSD only supports Xen on x86, not arm. So this is going to be > a bit of a challenge to get a Xen FreeBSD guest on arm working. We know > Julien Grall has some patches that made it work in the past ! > > I found a slightly newer slide presentation by Julien here: > > https://www.slideshare.net/xen_com_mgr/bsdcan-2015-how-to-port-your-bsd > > It is about the same, but it mentions the GENERIC FreeBSD kernel supports > Xen on arm64, but still says we need the XENHVM FreeBSD config for Xen on > arm 32 bit, which I haven't found online yet. > > Please,take a look at this output of the linux kernel that can boot on > Xen, and the FreeBSD kernel that cannot : > > > % file zImage-6.1.59-stb-xen-cbe+ > zImage-6.1.59-stb-xen-cbe+: Linux kernel ARM boot executable zImage (litt= le-endian) > > % file FREEBSD-XENVIRT > FREEBSD-XENVIRT: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), = dynamically linked, interpreter /red/herring, for FreeBSD 11.0 (1100048), n= ot stripped > > > The FreeBSD kernel that won't boot is in ELF format but the Linux kernel > that does boot is in zImage format. > > I spent time reading the docs on xenbits.xenproject.org, and according to > those docs Xen on arm only knows how to boot a kernel in the zImage forma= t, > so the FreeBSD kernel is in a format that modern Xen incorrectly detects = as > an x86 kernel. > > I also watched Julien Grall's 30 minute video presentation of his work to > boot FreeBSD/arm on Xen at FOSDEM 2014 here : > > https://archive.fosdem.org/2014/schedule/event/freebsd_xen_arm/ > > In that video, and in other places, Julien mentions that the boot ABI for > FreeBSD/arm on Xen was not yet developed and he was getting occasional > crashes and needed to investigate the problem. He mentioned the zImage AB= I > that Linux uses, but pointed out FreeBSD does not use that format, and ba= ck > then it was an open question which format to use to boot FreeBSD/arm on > Xen. Unfortunately, nine years later, the only supported format is still > the zImage format that Linux uses. > > It looks like Julien's work back then was using an ELF binary to boot > FreeBSD/arm on Xen instead of the supported zImage format that Linux uses > and the modern Xen toolstack exits with an error when trying to boot the > FreeBSD ELF formatted binary that Julien's patch creates. So the best > solution would be to try to port the rules to build a FreeBSD kernel in t= he > zImage format instead of the ELF format. I have been studying the Makefil= es > in Linux to see how Linux builds the Linux arm kernel in the zImage forma= t, > but it is not trivial to understand > Look at kernel.bin in FreeBSD's kernel. It's enabled -DWITH_KERNEL_BIN. It should be easy to adapt the target to build that. I've done similar things with u-boot formats in the past, but that was 4 employers and 20 years ago now. This path is not well trod. I do know that arm64 virtualization with bhyve is hitting the tree. I'm not sure how easy/hard this will be to modernize. I'm interested to see how your explorations go. Warner --00000000000021c269060afd0a2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Nov 25, 2023 at 4:41=E2=80=AF= AM Mario Marietto <marietto200= 8@gmail.com> wrote:
Hel= lo to everyone.

we have just virtualized Debian 12 on our arm (= 32 bit) Chromebook. As host / dom0 we have chosen Devuan 5,and for guest / domU,Debian 12. It=20 works great. But our goal is different. We want to virtualize FreeBSD as domU. Can we have a working Xen PV network driver for a FreeBSD arm=20 guest ?. I found that Julien Grall has ported the Xen drivers to FreeBSD on arm. I would like to know if Julien's work was accepted upstream by= =20 FreeBSD, in which case FreeBSD as a Xen guest on arm should work if we=20 enable the Xen PV drivers in the FreeBSD on arm kernel. If Julien's wor= k was not accepted upstream by FreeBSD, we will have to find his patches=20 and apply them ourselves to the FreeBSD on arm kernel.

We found these slides :

https://events.static.linuxfound.org/sites/events/file= s/slides/Porting%20FreeBSD%20on%20Xen%20on%20ARM%20.pdf

Slide 13 refers to a XENHVM FreeBSD on arm kernel config - that is what = we want to find.

It looks like when that slide presentation was written, there were=20 some limitations on FreeBSD Xen guests. For example, for our debian=20 bookworm guest, I am using vcpus =3D '2' to match the number of rea= l cpus=20 on our Chromebook, but slide 13 mentions support for only 1 VCPU with a=20 FreeBSD guest, so I will need to change that vcpus =3D '1' in the F= reeBSD=20 guest config unless support for 2 or more vcpus was added later, which=20 is possible because that slide presentation is 9 years old.

Here is where I would expect to find the XENHVM FreeBSD on arm kernel co= nfig file:

https://cgit.freebsd.org/src/tree/sys/arm/= conf

But it is not there unless I am not understanding something=20 correctly. For now, unfortunately conclude that the support for Xen on=20 arm that Julien Grall mentioned in that slide presentation 9 years ago=20 was never added to the official FreeBSD source code. I am searching the=20 web now to see if the patches that Julien Grall wrote are still posted=20 somewhere online. If we cannot find them, we can ask here and on the=20 xen-users mailing list. Julien regularly reads that list and responds to question about Xen on arm, so I think he will tell us how to find the=20 patches if we cannot find them online.

According to this page from the FreeBSD wiki:

https://wiki.freebsd.org/Xen

I think FreeBSD only supports Xen on x86, not arm. So this is going=20 to be a bit of a challenge to get a Xen FreeBSD guest on arm working. We know Julien Grall has some patches that made it work in the past !

I found a slightly newer slide presentation by Julien here:

https://www.slide= share.net/xen_com_mgr/bsdcan-2015-how-to-port-your-bsd

It is about the same, but it mentions the GENERIC FreeBSD kernel=20 supports Xen on arm64, but still says we need the XENHVM FreeBSD config=20 for Xen on arm 32 bit, which I haven't found online yet.

Please,take a look at this output of the linux kernel that can boot on X= en, and the FreeBSD kernel that cannot :


% file zImage-6.1.59-stb-xen-cbe+
zImage-6.1.59-stb-xen-cbe+: Linux kernel ARM boot executable zImage (little=
-endian)

% file FREEBSD-XENVIRT         =20
FREEBSD-XENVIRT: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dy=
namically linked, interpreter /red/herring, for FreeBSD 11.0 (1100048), not=
 stripped


The FreeBSD kernel that won't boot is in ELF format but t= he Linux kernel that does boot is in zImage format.

I spent time reading the docs on xenbits.xenproject.org, and=20 according to those docs Xen on arm only knows how to boot a kernel in=20 the zImage format, so the FreeBSD kernel is in a format that modern Xen=20 incorrectly detects as an x86 kernel.

I also watched Julien Grall's 30 minute video presentation of his wo= rk to boot FreeBSD/arm on Xen at FOSDEM 2014 here :

https://archive.fosdem.or= g/2014/schedule/event/freebsd_xen_arm/

In that video, and in other places, Julien mentions that the boot ABI for FreeBSD/arm on Xen was not yet developed and he was getting=20 occasional crashes and needed to investigate the problem. He mentioned=20 the zImage ABI that Linux uses, but pointed out FreeBSD does not use=20 that format, and back then it was an open question which format to use=20 to boot FreeBSD/arm on Xen. Unfortunately, nine years later, the only=20 supported format is still the zImage format that Linux uses.

It looks like Julien's work back then was using an ELF binary to boo= t FreeBSD/arm on Xen instead of the supported zImage format that Linux=20 uses and the modern Xen toolstack exits with an error when trying to=20 boot the FreeBSD ELF formatted binary that Julien's patch creates. So= =20 the best solution would be to try to port the rules to build a FreeBSD=20 kernel in the zImage format instead of the ELF format. I have been=20 studying the Makefiles in Linux to see how Linux builds the Linux arm=20 kernel in the zImage format, but it is not trivial to understand

<= /div>

Look at kernel.bin = in FreeBSD's kernel. It's enabled -DWITH_KERNEL_BIN. It should be e= asy to adapt the target to build that. I've done similar things with u-= boot formats in the past, but that was 4 employers and 20 years ago now.

This path is not well trod. I do know that arm64= virtualization with bhyve is hitting the tree. I'm not sure how easy/h= ard this will be to modernize. I'm interested to see how your explorati= ons go.

Warner
--00000000000021c269060afd0a2c--