From owner-freebsd-arm@freebsd.org Mon Dec 23 01:14:09 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0436B1E15BC for ; Mon, 23 Dec 2019 01:14:09 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47h1b35vnrz43Th for ; Mon, 23 Dec 2019 01:14:07 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wr1-x442.google.com with SMTP id t2so15043511wrr.1 for ; Sun, 22 Dec 2019 17:14:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=ZU/cMLbT1I6+XyCO8DEyPiGaIvLgkt37Mtunu4o3YwY=; b=BG9erqXIJpFgpFG++qfj0PWdo0K1o5nX0gGF6KEhD9dRvfqpDwc1ndfSznrpRLl555 cG82B9ZXt2xSdVhKr4J8Zf2jP23HmprKGcPLOlwoFgycEa9IGNviEGmcBE4u0/uTvLft JVKALGwkmRm2UX6C14RNOuTmzbKp+vZo+5n6o8pBGQizmoBQNpS+4BQxriPbHWByNpoF hRMf/vZ4eUCfEQL6E+Hm6MuGnKLYEf6hxngyeVU9NZ9s6LHJRyly8zHvz5r7wZUJrCQ3 /xO/JEruUZlPA6Dy3rnhbvn9SBffnAQHnNvWLafC/fa4q2OpZekBiYcdC+WtcuHHK1Op dO+w== X-Gm-Message-State: APjAAAVtotdANgzAzKlLlyAIIOW9IYvKIi56DdLqYf11PlJ+tMjlVALw G6ci8M4UA3wG7F02jPVeHI4= X-Google-Smtp-Source: APXvYqyYFHMQ0g1fWN3o31pTgZpfgTjiHmg3ryEi7WanTmA2/bxxxPECJLlnfxBGf5isa8EF5z89Ug== X-Received: by 2002:a5d:4a84:: with SMTP id o4mr26831378wrq.396.1577063644769; Sun, 22 Dec 2019 17:14:04 -0800 (PST) Received: from [192.168.1.166] (x59cc995a.dyn.telefonica.de. [89.204.153.90]) by smtp.googlemail.com with ESMTPSA id x17sm18468008wrt.74.2019.12.22.17.14.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Dec 2019 17:14:04 -0800 (PST) From: =?utf-8?Q?Klaus_K=C3=BCchemann?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: Attempt to update Rock64 to head -r355976 failed to boot afterwards, anyone have a recent FreeBSD booting a Rock64? Date: Mon, 23 Dec 2019 02:14:02 +0100 References: <78081E30-3758-46F3-A228-02B29CDAA6A6.ref@yahoo.com> <78081E30-3758-46F3-A228-02B29CDAA6A6@yahoo.com> <20191222113844.9385de125afd10e86358bc98@bidouilliste.com> <3C550401-A5BF-441E-81E6-29D5D917302B@yahoo.com> <0AADC2F5-9867-40E7-B4C0-139CA16A3974@yahoo.com> <6DAB33B7-0627-40AA-81DB-9853EAB7FB6D@yahoo.com> To: Mark Millard , freebsd-arm@freebsd.org In-Reply-To: <6DAB33B7-0627-40AA-81DB-9853EAB7FB6D@yahoo.com> Message-Id: <8BA15674-DDF6-4BA2-847D-211ABDFEE94D@googlemail.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Rspamd-Queue-Id: 47h1b35vnrz43Th X-Spamd-Bar: - X-Spamd-Result: default: False [-1.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[90.153.204.89.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2.4.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (2.44), ipnet: 2a00:1450::/32(-2.65), asn: 15169(-1.89), country: US(-0.05)]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 01:14:09 -0000 I=E2=80=99m using a =E2=80=99special=E2=80=99 2019.10 u-boot - version = ,developed by a BSD-colleague, where the dtb-clock-settings were backported to 2019.10 u-boot for = Rock64. Before using that special version I=E2=80=99ve booted FreeBSD on the = Rock64 by typing 'boot disk0s2:/boot/kernel/kernel=E2=80=98 at the prompt with a = standard linux-uboot-version=20 by Ayufan . > Am 23.12.2019 um 01:24 schrieb Mark Millard via freebsd-arm = : >=20 > [The start_init: message was a dumb thing to use as a > reference point.] >=20 > On 2019-Dec-22, at 15:06, Mark Millard wrote: >=20 >> [It has taken explicitly controlling the DTB used and >> use of "boot -v" together to be able to boot to >> completion . . .] >>=20 >> On 2019-Dec-22, at 12:47, Mark Millard wrote: >>=20 >>> On 2019-Dec-22, at 11:16, Mark Millard wrote: >>>=20 >>>> On 2019-Dec-22, at 02:38, Emmanuel Vadot = wrote: >>>>=20 >>>>> On Sun, 22 Dec 2019 00:22:16 -0800 >>>>> Mark Millard via freebsd-arm wrote: >>>>>=20 >>>>>> [OverDrive 1000 and MACCHIATObin Doubleshot updates went fine. >>>>>> The code has Peter Jeremy's rk_tsadc.c patch.] >>>>>>=20 >>>>>>=20 >>>>>> The console shows for boot -v . . . >>>>>>=20 >>>>>>=20 >>>>>> Loading kernel... >>>>>> /boot/kernel/kernel text=3D0x98af14 data=3D0x18e618 = data=3D0x0+0x6fc8e8 syms=3D[0x8+0x142020+0x8+0x12d3fd] >>>>>> Loading configured modules... >>>>>> /boot/kernel/umodem.ko text=3D0x2120 text=3D0x13e0 = data=3D0x6e8+0x10 syms=3D[0x8+0xf60+0x8+0xb7f] >>>>>> /boot/kernel/ucom.ko text=3D0x217f text=3D0x3340 data=3D0x880+0x858= syms=3D[0x8+0x1170+0x8+0xb0d] >>>>>> /boot/entropy size=3D0x1000 >>>>>>=20 >>>>>> Hit [Enter] to boot immediately, or any other key for command = prompt. >>>>>> Booting [/boot/kernel/kernel] in 8 seconds...=20 >>>>>>=20 >>>>>> Type '?' for a list of commands, 'help' for more detailed help. >>>>>> OK boot -v >>>>>> Using DTB provided by EFI at 0x80f3000. >>>>>> ---<>--- >>>>>> . . . >>>>>=20 >>>>>=20 >>>>> I don't have the same clocks from the dtb, make sure that you are >>>>> using the latest one. >>>>> rk3328_cru0: mem = 0xff440000-0xff440fff on ofwbus0 >>>>> . . . >>>>> sha256 /boot/dtb/rockchip/rk3328-rock64.dtb=20 >>>>> SHA256 (/boot/dtb/rockchip/rk3328-rock64.dtb) =3D = 50a180fed37f1d5dbfda60a6c55261c7b87b5b2bc97e428042481c94877da317 >>>>=20 >>>> Thanks. >>>>=20 >>>> # sha256 /mnt/boot/dtb/rockchip/rk3328-rock64.dtb >>>> SHA256 (/mnt/boot/dtb/rockchip/rk3328-rock64.dtb) =3D = 50a180fed37f1d5dbfda60a6c55261c7b87b5b2bc97e428042481c94877da317 >>>>=20 >>>> Looks like a match to me. So I need to look elsewhere than >>>> the contents of that file . . . >>>>=20 >>>> My getting: "Using DTB provided by EFI at 0x80f3000" suggests >>>> that the file is not being used for some reason: Instead some >>>> sort of nonFreeBSD/internal-to-something-else DTB seems to be >>>> in use? >>>>=20 >>>> So my current guess is that I need to figure out how to control >>>> which DTB source is used so that = /boot/dtb/rockchip/rk3328-rock64.dtb >>>> is used in my context. (Although I've no clue why I'd need a >>>> different configuration for controlling such things now.) >>>>=20 >>>> Note: I tried putting back the prior EFI/BOOT/bootaa64.efi but >>>> it made no difference to the failed-boot behavior. >>>=20 >>> Well, using load -t explicitly got farther: >>> (So once I figure out an equivalent in /boot/loader.conf >>> it should automatically get farther.) >> . . . >>=20 >> The following forced the desired .dtb to be used: >>=20 >> # more /boot/loader.conf=20 >> . . . >> rk3328_rock64_load=3D"YES" >> rk3328_rock64_type=3D"dtb" >> rk3328_rock64_name=3D"/boot/dtb/rockchip/rk3328-rock64.dtb" >> . . . >>=20 >> Interestingly, so far, boot -v works for power up booting, >> but default booting does not, even for when "boot" is >> typed to the loader prompt. >>=20 >> The default usually just hangs instead of showing all >> the information that I reported previously. The hangup >> (possibly with some text) is just before the start_init >> line in: >>=20 >> Warning: no time-of-day clock registered, system time will not be set = accurately >> start_init: trying /sbin/init >=20 > This was a dumb choice of reference point: >=20 > while ((path =3D strsep(&tmp_init_path, ":")) !=3D NULL) { > if (bootverbose) > printf("start_init: trying %s\n", path); >=20 > The message only shows up for bootverbose in the first place. >=20 >> So far, no hang-up has shown part of the "start_init" >> message line. >=20 > Again, a dumb reference point to have used. >=20 > A normal boot shows: >=20 > . . . > Root mount waiting for: CAM > Warning: no time-of-day clock registered, system time will not be set = accurately > Setting hostuuid: . . . > Setting hostid: . . . > Starting file system checks: > . . . >=20 > So the real range for failure is between: >=20 > Warning: no time-of-day clock registered, system time will not be set = accurately > Setting hostuuid: . . . >=20 >=20 >> But I've not had troubles (so far) with "shutdown -r now" >> reboots, defaults or otherwise: problems Just for going >> from power-off to power-on and trying to boot. >>=20 >> (Someday, I also want to figure out how to set up the >> Rock64 to get a stable DHCP binding: a fixed MAC >> address, I guess.) >>=20 >=20 > So far, trying a debug kernel is like trying "boot -v": the > problem has not occurred (and there are no interesting > messages). >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"