BananaPi M2 support

Sergey Suloev ssuloev at orpaltech.com
Wed Nov 18 06:14:31 EST 2020


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




More information about the linux-arm-kernel mailing list