Re: Bug#928612: u-boot-sunxi: Enable support for NanoPi NEO2

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Bug#928612: u-boot-sunxi: Enable support for NanoPi NEO2

Domenico Andreoli-3
Hi,

On Tue, May 07, 2019 at 09:50:58AM -0700, Vagrant Cascadian wrote:
> On 2019-05-07, Domenico Andreoli wrote:
> >   Salsa MR #5 enables support for NanoPi NEO 2. I tested it with Buster
> > RC1 installer, althought it resulted in a non-bootable system u-boot
> > worked well enough.
>
> Just for clarity, you're saying the non-bootability was unrelated to
> u-boot, but u-boot was able to boot a kernel + initrd + dtb?

u-boot is able to find the USB stick with the Buster RC1 installer and
boot it. I made many cycles, this happens reliably.

The first road block is the partitioner, if let alone it creates a
regular GPT (don't know if it could be instructed to create a legacy MBR
instead) and so overwrites the spl+u-boot leaving the board completely
unbootable.

To work around this, I prepare the GPT manually with the famous 4 entries
(see the extra menu in fdisk) and configure the partitions at my wish,
then the installer can reuse them preserving my hand crafted GPT and
the bootability up to u-boot.

The installation process goes nicely but grub installation fails,
as it seems to be expected [0]. The board is left unbootable.

This is where I am, so booting kernel+initrd+dtb: yes (the installer
from USB), no (the just installed system).

To be fair, I should check that the installer can be executed via tftp
and via partition on the sdcard before claiming it's all fine with
u-boot on this board.

Need to further investigate why u-boot cannot continue the boot. I
don't know how a properly working arm64 world looks like and what's
missing from my installation, if it's not just grub.

I am not able to quickly hack a boot, the kernel is not just a familiar
zImage and bootz is not even available. It must have something to do
with all this UEFI order of things for which I need grub (or not?) ;)

>
> I made some comments on the merge request to reduce the diff so it would
> be possible to get into buster.

I think I addressed all your comments, MR #5 is updated for sid while
#6 is ready for master.

>
> Thanks!
>
> live well,
>   vagrant

thanks,
Domenico

[0] https://wiki.debian.org/InstallingDebianOn/Allwinner

--
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13

Reply | Threaded
Open this post in threaded view
|

Re: Bug#928612: u-boot-sunxi: Enable support for NanoPi NEO2

Domenico Andreoli-3
On Wed, May 08, 2019 at 06:28:28PM +0200, Domenico Andreoli wrote:
> On Tue, May 07, 2019 at 09:50:58AM -0700, Vagrant Cascadian wrote:
> > On 2019-05-07, Domenico Andreoli wrote:
> > >   Salsa MR #5 enables support for NanoPi NEO 2. I tested it with Buster
> > > RC1 installer, althought it resulted in a non-bootable system u-boot
> > > worked well enough.
> >
> > Just for clarity, you're saying the non-bootability was unrelated to
> > u-boot, but u-boot was able to boot a kernel + initrd + dtb?

[...]

> Need to further investigate why u-boot cannot continue the boot. I
> don't know how a properly working arm64 world looks like and what's
> missing from my installation, if it's not just grub.
>
> I am not able to quickly hack a boot, the kernel is not just a familiar
> zImage and bootz is not even available. It must have something to do
> with all this UEFI order of things for which I need grub (or not?) ;)
>

Last minute update is that I run the Buster RC1 installer in rescue
mode and installed grub as removable device. Now u-boot loads grub
nicely and from there the system is booted flawlessly.

The normal method of installing grub fails because no UEFI is there to
handle the configuration of the new entry:

Installing for arm64-efi platform.
grub-install: warning: Cannot set EFI variable Boot0000.
grub-install: warning: efivarfs_set_variable: writing to fd 6 failed: Input/output error.
grub-install: warning: efivarfs_set_variable: failed to unlink /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c: Invalid argument.
grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: Input/output error.
grub-install: error: failed to register the EFI boot entry: Input/output error.

Regards,
Domenico

--
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13

Reply | Threaded
Open this post in threaded view
|

Re: Bug#928612: u-boot-sunxi: Enable support for NanoPi NEO2

andreimpopescu
In reply to this post by Domenico Andreoli-3
On Mi, 08 mai 19, 18:28:28, Domenico Andreoli wrote:
>
> The first road block is the partitioner, if let alone it creates a
> regular GPT (don't know if it could be instructed to create a legacy MBR
> instead) and so overwrites the spl+u-boot leaving the board completely
> unbootable.

It's possible to create other partition table types in expert mode.
However, in my experience even an 'msdos' partition table messed up
u-boot.

> To work around this, I prepare the GPT manually with the famous 4 entries
> (see the extra menu in fdisk) and configure the partitions at my wish,
> then the installer can reuse them preserving my hand crafted GPT and
> the bootability up to u-boot.

It is sufficient to just create the partition table, deleting and adding
partitions from the installer (manual partitioning) should be safe.

> The installation process goes nicely but grub installation fails,
> as it seems to be expected [0]. The board is left unbootable.

Just curios, since I'm not familiar with this particular board, but why
do you need grub if you already have u-boot?

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug#928612: u-boot-sunxi: Enable support for NanoPi NEO2

Domenico Andreoli-3
On Wed, May 08, 2019 at 11:07:10PM +0300, Andrei POPESCU wrote:

> On Mi, 08 mai 19, 18:28:28, Domenico Andreoli wrote:
> >
> > The first road block is the partitioner, if let alone it creates a
> > regular GPT (don't know if it could be instructed to create a legacy MBR
> > instead) and so overwrites the spl+u-boot leaving the board completely
> > unbootable.
>
> It's possible to create other partition table types in expert mode.
> However, in my experience even an 'msdos' partition table messed up
> u-boot.

Cool!

>
> > To work around this, I prepare the GPT manually with the famous 4 entries
> > (see the extra menu in fdisk) and configure the partitions at my wish,
> > then the installer can reuse them preserving my hand crafted GPT and
> > the bootability up to u-boot.
>
> It is sufficient to just create the partition table, deleting and adding
> partitions from the installer (manual partitioning) should be safe.

Verified, changing the layout from there results in a complete GPT rewrite.

>
> > The installation process goes nicely but grub installation fails,
> > as it seems to be expected [0]. The board is left unbootable.
>
> Just curios, since I'm not familiar with this particular board, but why
> do you need grub if you already have u-boot?

I wondered the same and in a more hacky attempt I made more than one
year ago, with older hand-crafted installed with a 4.15 kernel, I came
to the conclusion that Debian arm64 was u-boot+grub with a scent of UEFI.

I aim at the most streamlined installation with the most support out
of the box and least divergence from a standard setup. I've got a fully
reproducible and, I hope, maintainable installation.

Now I would like to contribute what bits are missing and update the
wiki page so to save some time to the next one attempting the same.

>
> Kind regards,
> Andrei

Regards,
Domenico

--
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13

Reply | Threaded
Open this post in threaded view
|

Re: Bug#928612: u-boot-sunxi: Enable support for NanoPi NEO2

andreimpopescu
On Jo, 09 mai 19, 07:58:39, Domenico Andreoli wrote:
> On Wed, May 08, 2019 at 11:07:10PM +0300, Andrei POPESCU wrote:
> >
> > It is sufficient to just create the partition table, deleting and adding
> > partitions from the installer (manual partitioning) should be safe.
>
> Verified, changing the layout from there results in a complete GPT rewrite.
 
I feel like we are talking past each other. What I mean is that, in my
experience, having u-boot installed on a media (in my case SD card for
PINE A64+) and a msdos partition table in the installer one can
delete/add partitions (manual instead of guided partitioning) and the
media remains bootable.

Rewriting the partition *table*, even if msdos will make the media
un-bootable.
 
> > > The installation process goes nicely but grub installation fails,
> > > as it seems to be expected [0]. The board is left unbootable.
> >
> > Just curios, since I'm not familiar with this particular board, but why
> > do you need grub if you already have u-boot?
>
> I wondered the same and in a more hacky attempt I made more than one
> year ago, with older hand-crafted installed with a 4.15 kernel, I came
> to the conclusion that Debian arm64 was u-boot+grub with a scent of UEFI.
 
Much has happened in a year, in particula a new upstream u-boot with
much better support out-of-the-box for a lot of devices/SoCs.

> I aim at the most streamlined installation with the most support out
> of the box and least divergence from a standard setup. I've got a fully
> reproducible and, I hope, maintainable installation.

See https://wiki.debian.org/InstallingDebianOn/PINE64/PINEA64 for a
general outline of my steps.

For devices without a pre-made image with u-boot there are two
additional steps required: create the partition table (easy) and install
u-boot (undocumented).

For sunxi devices there is u-boot-install-sunxi64, but it only supports
a handful of devices.

Hope this helps,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug#928612: u-boot-sunxi: Enable support for NanoPi NEO2

Domenico Andreoli-3
On Thu, May 09, 2019 at 10:08:07AM +0300, Andrei POPESCU wrote:
> On Jo, 09 mai 19, 07:58:39, Domenico Andreoli wrote:
> >
> > I aim at the most streamlined installation with the most support out
> > of the box and least divergence from a standard setup. I've got a fully
> > reproducible and, I hope, maintainable installation.
>
> See https://wiki.debian.org/InstallingDebianOn/PINE64/PINEA64 for a
> general outline of my steps.

I was missing the flash-kernel support, I've just created a MR for it [0].
Would expect grub is not be needed on nanopi_neo2 then.

>
> For devices without a pre-made image with u-boot there are two
> additional steps required: create the partition table (easy) and install
> u-boot (undocumented).

I also made the MR for adding the pre-made image [1]. I hope it will
be included in next RC2 ;)

>
> For sunxi devices there is u-boot-install-sunxi64, but it only supports
> a handful of devices.

Vagrant has just merged support nanopi_neo2 there [2].

>
> Hope this helps,
> Andrei

Thanks,
Domenico

[0] https://salsa.debian.org/installer-team/flash-kernel/merge_requests/5
[1] https://salsa.debian.org/installer-team/debian-installer/merge_requests/9
[2] https://salsa.debian.org/debian/u-boot/merge_requests/5

--
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13

signature.asc (849 bytes) Download Attachment