On Mon, 16 Sept 2024, 18:51 Peter Robinson, <pbrobin...@gmail.com> wrote:
> > > On Mon, 16 Sept 2024, 17:27 Adrian Torregrosa, < > adrian.torregr...@gmail.com> wrote: > >> Hello. >> >> With U-Boot 2024.10 my Orange Pi simply freezes after some time. Once >> that was around 30 minutes, but most times the boot process does not >> finish, it freezes after anything between 5 and 60 seconds. That means it >> does not always stop at a particular step of the boot process. >> >> I reverted back to the 2023.10 version, and it booted first try. Quite >> likely there are several differences between 2023.10 and 2024.10 and at >> least one of those changes is causing those freezes. If it is worth still >> supporting the Orange Pi Zero Plus I'd suggest producing intermediate >> versions with less changes, so that we can determine which change causes >> the freeze. >> > > What is the rating of USB power supply you're using to power it? > Also did you try any of the kernel command line options I asked if you could? > BR >> >> -----Original Message----- >> *From*: Peter Robinson <pbrobin...@gmail.com >> <peter%20robinson%20%3cpbrobin...@gmail.com%3e>> >> *To*: Adrian Torregrosa <adrian.torregr...@gmail.com >> <adrian%20torregrosa%20%3cadrian.torregr...@gmail.com%3e>> >> *Cc*: arm@lists.fedoraproject.org >> *Subject*: Re: [fedora-arm] U-Boot 2024.10 testing >> *Date*: 2024.09.04 13:08:07 >> >> Hey, >> >> Yes, the boot completed on the Banana Pi M64. >> >> This morning I tried upgrading my Orange Pi Zero Plus to the rc3 U-Boot, >> and before rebooting I added those options below. It booted successfully: >> >> >> When you say "added the options below" you mean the debug ones I >> provided? To clarify it boots fine with the debug options and doesn't >> boot without them? >> >> If that is the case can you try adding these 3 kernel command line >> options "clk_ignore_unused pd_ignore_unused reg_ignore_unused" >> >> Probably add all 3 to begin with and see if it boots, then if you have >> time try combinations of the 3 to see if any particular one causes it >> to stop booting. >> >> Then I reverted the kernel options back to their previous valuse and I >> haven't been able to get it to boot again. >> >> I think I have to simply consider this device as unreliable. >> >> >> So depending on the above I suspect what is happening is that in older >> versions of firmware (U-Boot and friends) there was something that was >> turned on, likely by accident, that the kernel needs to boot but >> U-Boot doesn't and when the kernel starts to boot what is expected to >> be there isn't and hence the lack of boot. >> >> My Raspberry Pi and my Rock Pi E have always upgraded fine at the first >> attempt. No more Allwinner devices for me. >> >> >> I suspect we're just a little unlucky here, overall I have found all >> to have their pluses and their minuses, it all depends on uses cases. >> >> Let me know how you get on with the above. I don't think the issue is >> related to U-Boot, and the M64 is fine, so this update certainly makes >> the overall Allwinner support in Fedora better so it would be great if >> you can update the karma so we can get this into stable while we work >> out where the problem lies with the Orange Pi Zero Plus. >> >> P >> >> BR >> >> -----Original Message----- >> From: Peter Robinson <pbrobin...@gmail.com> >> To: Adrian Torregrosa <adrian.torregr...@gmail.com> >> Cc: arm@lists.fedoraproject.org >> Subject: Re: [fedora-arm] U-Boot 2024.10 testing >> Date: 2024.09.03 19:37:56 >> >> On Tue, 3 Sept 2024 at 18:21, Adrian Torregrosa >> <adrian.torregr...@gmail.com> wrote: >> >> >> After reverting back to 2023.07 on the Banana Pi M64 I booted and >> repeated the dd command. Before rebooting I took the time to read back from >> the MMC and compare its SHA256 checksum with that of the file >> /usr/share/uboot/bananapi_m64/u-boot-sunxi-with-spl.bin and that that >> appears in >> https://koji.fedoraproject.org/koji/fileinfo?rpmID=39921997&filename=/usr/share/uboot/bananapi_m64/u-boot-sunxi-with-spl.bin, >> and the three matched. >> >> Then I rebooted and the boot process completed successfully. >> >> >> So it completed successfully on the Banana Pi M64? >> >> One difference I observed was that when it failed it showed: >> >> >> So on a clean system that hasn't booted previously (with the feature) >> the OS hasn't updated the EFI entry. >> >> *** U-Boot Boot Menu *** >> >> mmc 0 >> whereas when it succeeded it showed >> *** U-Boot Boot Menu *** >> >> Fedora >> mmc 0 >> >> >> That's post boot where the UEFI entry was updated for the OS. >> >> Besides, this error that appears when it failed: >> error: ../../grub-core/disk/efi/efidisk.c:615:failure reading sector >> 0x1e6f80 from `hd0'. >> might be a transient one, I'm not sure about that. >> >> >> That looks like a problem with an SD card, I wonder if there's a >> failed sector or something. >> >> I can't say much more about why the upgrade failed on the Banana Pi the >> first time while it succeeded the second time. I'll see what I can find >> with the Orange Pi. >> >> >> Sometimes adding the following to the kernel command line can give you >> a bunch of very early boot debug output which may shed more of a light >> as to where the failure is "console=tty0 console=ttyS0,115200 earlycon >> uefi_debug earlyprintk=serial,ttyS0,115200 debug" >> >> Peter >> >> BR >> >> -----Original Message----- >> From: Peter Robinson <pbrobin...@gmail.com> >> To: Adrian Torregrosa <adrian.torregr...@gmail.com> >> Cc: arm@lists.fedoraproject.org >> Subject: Re: [fedora-arm] U-Boot 2024.10 testing >> Date: 2024.09.03 17:08:18 >> >> On Tue, 3 Sept 2024 at 16:03, Adrian Torregrosa >> <adrian.torregr...@gmail.com> wrote: >> >> >> The grub menu is reached in both cases. Then, the boot fails on the >> Banana Pi M64 just after a couple of seconds, whereas on the Orange Pi Zero >> Plus it simply does not complete the boot. >> >> >> Please debug it rather than just going straight out and giving >> negative karma because I don't believe U-Boot is the problem here, and >> it's significantly better than the previous version.... >> >> BR >> >> -----Original Message----- >> From: Peter Robinson <pbrobin...@gmail.com> >> To: Adrian Torregrosa <adrian.torregr...@gmail.com> >> Cc: arm@lists.fedoraproject.org >> Subject: Re: [fedora-arm] U-Boot 2024.10 testing >> Date: 2024.09.03 16:49:21 >> >> On Tue, 3 Sept 2024 at 15:42, Adrian Torregrosa >> <adrian.torregr...@gmail.com> wrote: >> >> >> Hello. >> >> I'm afraid the new release did not work for any of my two Allwinner >> devices. The dd commands went through of course but upon rebooting the >> devices failed to reach the login; please see the console outputs attached. >> >> >> Those outputs look like I would expect for a working device, I would >> expect the grub menu to come up shortly after that. What are you >> seeing? >> >> Peter >> >> BR >> >> -----Original Message----- >> From: Peter Robinson <pbrobin...@gmail.com> >> To: Adrian Torregrosa <adrian.torregr...@gmail.com> >> Cc: arm@lists.fedoraproject.org >> Subject: Re: [fedora-arm] U-Boot 2024.10 testing >> Date: 2024.09.02 23:31:09 >> >> Hi Adrian, >> >> I created Bug 2309138 - Allwinner A64 devices fail to boot once their >> uboot gets upgraded to 2024.04. >> >> >> So I think uboot-tools-2024.10-0.3.rc3.fc41 should fix the Allwinner >> issues, if you could test it and provide karma on the update below >> that would be fab. I tested it on my Pine64+ >> >> https://bodhi.fedoraproject.org/updates/FEDORA-2024-dbf55dbc52 >> >> I upgraded mi Radxa Rock Pi E with the UBoot in the rc2 .rpm and as far >> as I can tell it works fine: >> >> U-Boot TPL 2024.10-rc2 (Aug 15 2024 - 00:00:00) >> DDR3, 333MHz >> BW=32 Col=10 Bk=8 CS0 Row=14 CS=1 Die BW=16 Size=512MB >> Trying to boot from BOOTROM >> Returning to boot ROM... >> >> U-Boot SPL 2024.10-rc2 (Aug 15 2024 - 00:00:00 +0000) >> Trying to boot from MMC2 >> ## Checking hash(es) for config config-1 ... OK >> ## Checking hash(es) for Image atf-1 ... sha256+ OK >> ## Checking hash(es) for Image u-boot ... sha256+ OK >> ## Checking hash(es) for Image fdt-1 ... sha256+ OK >> ## Checking hash(es) for Image atf-2 ... sha256+ OK >> ## Checking hash(es) for Image atf-3 ... sha256+ OK >> NOTICE: BL31: v2.10.4(release): >> NOTICE: BL31: Built : 00:00:00, Jul 17 2024 >> NOTICE: BL31:Rockchip release version: v1.2 >> >> >> U-Boot 2024.10-rc2 (Aug 15 2024 - 00:00:00 +0000) >> >> Model: Radxa ROCK Pi E >> DRAM: 512 MiB (effective 510 MiB) >> PMIC: RK805 (on=0x40, off=0x01) >> Core: 244 devices, 29 uclasses, devicetree: separate >> MMC: mmc@ff500000: 1, mmc@ff520000: 0 >> Loading Environment from MMC... Reading from MMC(1)... *** Warning - bad >> CRC, using default environment >> >> In: serial@ff130000 >> Out: serial@ff130000 >> Err: serial@ff130000 >> Model: Radxa ROCK Pi E >> Net: eth0: ethernet@ff540000 >> Found DTB: rockchip/rk3328-rock-pi-e.dtb >> Card did not respond to voltage select! : -110 >> >> *** U-Boot Boot Menu *** >> >> Fedora >> mmc 1 >> Exit >> >> >> Press UP/DOWN to move, ENTER to select, ESC to quit >> Booting: Fedora >> Found DTB: rockchip/rk3328-rock-pi-e.dtb >> ethernet@ff540000 Waiting for PHY auto negotiation to complete....... >> done >> Speed: 1000, full duplex >> . >> . >> . >> >> >> >> >> Best regards. >> >> -----Original Message----- >> From: Peter Robinson <pbrobin...@gmail.com> >> To: Adrian Torregrosa <adrian.torregr...@gmail.com> >> Cc: arm@lists.fedoraproject.org >> Subject: Re: [fedora-arm] U-Boot 2024.10 testing >> Date: 2024.09.01 19:43:27 >> >> Hi Adrian, >> >> A couple of weeks ago I upgraded my Orange Pi Zero Plus and my Sinovoip >> Banana Pi M64, both of which are based on Allwinner 64, from F39 to F40. >> That went fine so after that I attempted upgrading their UBoots and that >> did not work: >> >> >> I think I've got to the bottom of the issue, any chance you can do a >> F-41 bug report for me? Link below should go straight there for you. >> >> >> https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=41&component=uboot-tools >> >> So I reverted back to U-Boot SPL 2023.07. >> >> This afternoon I tried upgrading the Banana Pi to this rc2 version and >> the result was quite similar: >> >> >> Yup, it's the same. >> >> For the record, I was able to upgrade my Raspberry Pi 3B's and my Radxa >> Rock Pi E's UBoots to 2024.04. >> >> >> What about to the 2024.10 RC builds in F-41? You can use the F-41 >> U-Boot without having to upgrade the OS. Mostly interested in the >> RockPi as I can test the RPi3. >> >> Thanks, >> Peter >> >> Best regards. >> >> -----Original Message----- >> From: Peter Robinson <pbrobin...@gmail.com> >> To: arm@lists.fedoraproject.org >> Subject: [fedora-arm] U-Boot 2024.10 testing >> Date: 2024.08.16 12:45:29 >> >> Hi Folks, >> >> I've started building the 2024.10 RCs in F-41+ so it would be great to >> get some testing. >> >> I found that at least the Allwinner a64 devices looked like they >> regressed in F-40 and I've tested the Pine64+ with the rc2 build and I >> think they should be OK now. >> >> It would be great if people could test and provide some feedback on >> these builds as we go towards F-41 beta freeze. >> >> https://koji.fedoraproject.org/koji/buildinfo?buildID=2530785 >> >> Peter >> >> >> >> >> >> >> >>
-- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
