Messages in this thread | | | Subject | Re: BananaPi M2 support | From | Sergey Suloev <> | Date | Wed, 18 Nov 2020 14:14:31 +0300 |
| |
Hi, ChenYu,
thanks for for the help. I tried to use "root=PARTUUID=a09ef512-7f29-47b8-8e9a-db5d1d58d8be" in kernel boot parameters, the new log is here https://pastebin.com/EL3uaRpE.
Nothing has actually changed, the only difference is that it now says:
[ 1.750270] Waiting for root device PARTUUID=a09ef512-7f29-47b8-8e9a-db5d1d58d8be...
I verified that a09ef512-7f29-47b8-8e9a-db5d1d58d8be is the actual partition id from my sdcard.
Thank you, Sergey
On 17.11.2020 20:36, Chen-Yu Tsai wrote: > Hi, > > On Wed, Nov 18, 2020 at 1:06 AM Sergey Suloev <ssuloev@orpaltech.com> wrote: >> Hi, ChenYu, >> >> I have tried to build and run linux-next by tag "next-20201117". >> Now the boot log looks different but the kernel still hangs. See >> https://pastebin.com/gFk7XuBc > Due to the new asynchronous probing of mmc controllers, the mmcblock > device numbers likely have changed, as seen here: > > [ 1.652275] mmc1: new high speed SDHC card at address 0001 > [ 1.652568] hub 1-1:1.0: USB hub found > [ 1.658587] mmcblk1: mmc1:0001 EB1QT 29.8 GiB > [ 1.661777] hub 1-1:1.0: 4 ports detected > [ 1.670263] mmcblk1: p1 > > You should change your root device specification to use PARTUUID, > instead of hardcoding the index. > > > Regards > ChenYu > >> Thank you, >> Sergey >> >> >> On 17.11.2020 11:06, Chen-Yu Tsai wrote: >>> Hi, >>> >>> Please try linux-next. There were some regulator fixes that got merged recently. >>> One of them fixes an infinite recursion when resolving regulator supplies. >>> >>> ChenYu >>> >>> On Tue, Nov 17, 2020 at 1:12 AM Sergey Suloev <ssuloev@orpaltech.com> wrote: >>>> Hi, Maxime, >>>> >>>> it just hangs on that last lines and nothing happens anymore, see 5.18 log. >>>> >>>> >>>> On 16.11.2020 18:52, Maxime Ripard wrote: >>>>> Hi, >>>>> >>>>> On Sat, Nov 14, 2020 at 08:20:54PM +0300, Sergey Suloev wrote: >>>>>> Hi, >>>>>> >>>>>> I noticed that BananaPi M2 (A31 SoC) does not boot anymore on modern >>>>>> kernels. The problem arises somewhere between 5.7.19 - 5.8.18. I have saved >>>>>> boot logs for both versions https://pastebin.com/DTRZi8R7 and >>>>>> https://pastebin.com/PS2hq07A. Logs have been taken on clean/non-patched >>>>>> kernel with default config, u-boot v2020.10. >>>>>> >>>>>> The kernel versions 5.7.x and below work well (I tried 5.5.19 and 5.6.19). >>>>>> The versions 5.8.18 and above all fail (5.9 and 5.10). >>>>>> >>>>>> Could you look at the problem or provide an advice about further >>>>>> investigation, please ? >>>>> I'm not quite sure what the issue is exactly? How does it fail to boot? >>>>> >>>>> Maxime >>>> Thank you, >>>> Sergey >>>>
| |