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? 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
