On Wed, Nov 18, 2020 at 7:14 PM Sergey Suloev <ssul...@orpaltech.com> wrote: > > 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.
That is the partition's UUID alright, but not what PARTUUID expects. PARTUUID is the partition table's ID + "-" + an index to the partition. If you're using an MBR partition table, and the partition is the first one, then it would be an 8 digit hexadecimal ID with "-01" appended. Just put the SD card in another machine and look under /dev/disks/by-partuuid/ to see what the value should be. ChenYu > 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 <ssul...@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 <ssul...@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 > >>>> >
