Re: Collecting GRUB 2.06 test results

[Glenn Washburn]

Hi John,

On Sat, 16 Jan 2021 19:26:26 +0100
John Paul Adrian Glaubitz  wrote:

> Hello!
> 
> On 1/4/21 4:24 PM, John Paul Adrian Glaubitz wrote:
> > I have started to collect test results for GRUB 2.06 here:
> > 
> >> https://people.debian.org/~glaubitz/grub2.06-test-results/
> 
> Just as a heads-up: I have collected test results for all
> architectures supported by GRUB. I have also verified GRUB works
> correctly on sparc64, I might perform full tests on other
> architectures later.

Thanks for this these tests. Are you running these tests on the
same architecture that you're testing? Or, for instance, running the
tests for all architectures on say x86_64?

I'd like to note that it appears that these tests do not perform most
of the various filesystem tests.

Also, I believe mips arch is not being tested here. And it appears that
none of the qemu tests for mipsle are being run due to not having qemu
for that arch installed.

None of the qemu tests are being run for most of the architectures (I
also haven't figured out how to get them to run on most architectures).
But I have gotten the qemu tests to run for arm and arm64, which they
are not running in your tests. What is especially odd, is that for
armhf grub-shell is looking for 'qemu-system-i386' and not finding it.
But it should be looking for the arm qemu variant.

For completeness, The risc architecture is not being tested either. Yes,
I know most tests fail because of a bug. Are we considering it an
unsupported platform because its unusable, even though it can be built?

Where is the list of architectures "supported" by GRUB? Or is it all
the ones allowed to be built by master?

Glenn

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Collecting GRUB 2.06 test results

[John Paul Adrian Glaubitz]

Hello Glenn!

On 2/10/21 8:21 PM, Glenn Washburn wrote:
> Thanks for this these tests. Are you running these tests on the
> same architecture that you're testing? Or, for instance, running the
> tests for all architectures on say x86_64?

Those were all tested on native hardware with a few exceptions:

- 32-bit PowerPC tests were run on a 64-bit PowerPC machine
- 32-bit MIPS tests were run on a 64-bit MIPS machine

I do have an iBook G4 and could run the 32-bit PowerPC tests there.

(Now I'm actually not sure anymore whether I ran the 32-bit PowerPC
 tests on the G4, but I can still do that. The machine is next to
 me, just currently powered off).

> I'd like to note that it appears that these tests do not perform most
> of the various filesystem tests.

I ran the tests with "make check" (or "make test"), I did not make
any modifications. If some tests were not run that's because GRUB does
not enable them on the target in question.

> Also, I believe mips arch is not being tested here. And it appears that
> none of the qemu tests for mipsle are being run due to not having qemu
> for that arch installed.

What do you mean by "here"?

> None of the qemu tests are being run for most of the architectures (I
> also haven't figured out how to get them to run on most architectures).
> But I have gotten the qemu tests to run for arm and arm64, which they
> are not running in your tests. What is especially odd, is that for
> armhf grub-shell is looking for 'qemu-system-i386' and not finding it.
> But it should be looking for the arm qemu variant.
> 
> For completeness, The risc architecture is not being tested either. Yes,
> I know most tests fail because of a bug. Are we considering it an
> unsupported platform because its unusable, even though it can be built?

I currently do not have access to a RISC-V machine yet. I have preordered
one and also applied for a developer machine from SiFive, but I haven't
gotten any yet.

> Where is the list of architectures "supported" by GRUB? Or is it all
> the ones allowed to be built by master?

You can see that by looking at the configure.ac. It's basically all targets
that build more than just the utilities.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Collecting GRUB 2.06 test results

[Glenn Washburn]

On Wed, 10 Feb 2021 20:29:41 +0100
John Paul Adrian Glaubitz  wrote:

> Hello Glenn!
> 
> On 2/10/21 8:21 PM, Glenn Washburn wrote:
> > Thanks for this these tests. Are you running these tests on the
> > same architecture that you're testing? Or, for instance, running the
> > tests for all architectures on say x86_64?
> 
> Those were all tested on native hardware with a few exceptions:
> 
> - 32-bit PowerPC tests were run on a 64-bit PowerPC machine
> - 32-bit MIPS tests were run on a 64-bit MIPS machine
> 
> I do have an iBook G4 and could run the 32-bit PowerPC tests there.
> 
> (Now I'm actually not sure anymore whether I ran the 32-bit PowerPC
>  tests on the G4, but I can still do that. The machine is next to
>  me, just currently powered off).

Ok, I'm glad you're running the tests on native hardware and in that
case I'm not surprised most of the qemu tests aren't running because I
assume that qemu is not on most of the non x86 platforms. Perhaps we
should have the tests show as SKIPPED when the appropriate qemu binary
can not be found.

> > I'd like to note that it appears that these tests do not perform
> > most of the various filesystem tests.
> 
> I ran the tests with "make check" (or "make test"), I did not make
> any modifications. If some tests were not run that's because GRUB does
> not enable them on the target in question.

That's technically true, but not the whole story. GRUB is not enabling
the filesystem tests because you don't have your target environment
setup such that the tests will be enabled. The filesystem tests require
filesystem tools (eg. e2fsprogs for ext* fs tests). You might try
installing the prerequisites needed by the tests, and then seeing if
they run.

> > Also, I believe mips arch is not being tested here. And it appears
> > that none of the qemu tests for mipsle are being run due to not
> > having qemu for that arch installed.
> 
> What do you mean by "here"?

I mean that it appears to me that you don't have tests for the mips
arch, only mipsle. I'm not very familiar with mips, so I may be
confusing. My understanding is that there are big and little endian
variants of the mips architecture, and 32 vs 64 bit variants. I
understand mipsle to indicate the little-endian variant, but GRUB
supports the big endian variant as well. It seems to me that you only
have test logs for the 32 and 64 bit little endian variants.

> > None of the qemu tests are being run for most of the architectures
> > (I also haven't figured out how to get them to run on most
> > architectures). But I have gotten the qemu tests to run for arm and
> > arm64, which they are not running in your tests. What is especially
> > odd, is that for armhf grub-shell is looking for 'qemu-system-i386'
> > and not finding it. But it should be looking for the arm qemu
> > variant.
> > 
> > For completeness, The risc architecture is not being tested either.
> > Yes, I know most tests fail because of a bug. Are we considering it
> > an unsupported platform because its unusable, even though it can be
> > built?
> 
> I currently do not have access to a RISC-V machine yet. I have
> preordered one and also applied for a developer machine from SiFive,
> but I haven't gotten any yet.
>
> > Where is the list of architectures "supported" by GRUB? Or is it all
> > the ones allowed to be built by master?
> 
> You can see that by looking at the configure.ac. It's basically all
> targets that build more than just the utilities.

Great, that's what I was thinking. I notice that it appears you're not
testing every supported target, just one target from each architecture.
For instance, you're not testing and i386 build of the ieee1275 or efi
platforms. 

Since you're not using qemu on the non-x86 platforms, I'm not sure if
testing the various platforms of other architectures would be worth
while (eg. arm-coreboot and arm-efi). Perhaps someone more
knowledgeable than I can weight in.

Glenn

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Collecting GRUB 2.06 test results

[John Paul Adrian Glaubitz]

Hi Glenn!

On 2/11/21 12:57 AM, Glenn Washburn wrote:
> Ok, I'm glad you're running the tests on native hardware and in that
> case I'm not surprised most of the qemu tests aren't running because I
> assume that qemu is not on most of the non x86 platforms. Perhaps we
> should have the tests show as SKIPPED when the appropriate qemu binary
> can not be found.

OK. I wasn't aware of that.

>>> I'd like to note that it appears that these tests do not perform
>>> most of the various filesystem tests.
>>
>> I ran the tests with "make check" (or "make test"), I did not make
>> any modifications. If some tests were not run that's because GRUB does
>> not enable them on the target in question.
> 
> That's technically true, but not the whole story. GRUB is not enabling
> the filesystem tests because you don't have your target environment
> setup such that the tests will be enabled. The filesystem tests require
> filesystem tools (eg. e2fsprogs for ext* fs tests). You might try
> installing the prerequisites needed by the tests, and then seeing if
> they run.

I can re-run them with the fsprogs installed. Does that just concern
e2fsprogs or other filesystems as well?

>>> Also, I believe mips arch is not being tested here. And it appears
>>> that none of the qemu tests for mipsle are being run due to not
>>> having qemu for that arch installed.
>>
>> What do you mean by "here"?
> 
> I mean that it appears to me that you don't have tests for the mips
> arch, only mipsle. I'm not very familiar with mips, so I may be
> confusing. My understanding is that there are big and little endian
> variants of the mips architecture, and 32 vs 64 bit variants. I
> understand mipsle to indicate the little-endian variant, but GRUB
> supports the big endian variant as well. It seems to me that you only
> have test logs for the 32 and 64 bit little endian variants.

Right. I didn't test big-endian MIPS because it's not part of the
Debian unstable distribution anymore (but Debian Buster). I will test
big-endian in a second test run, I have access to a big-endian MIPS
machine.

>> You can see that by looking at the configure.ac. It's basically all
>> targets that build more than just the utilities.
> 
> Great, that's what I was thinking. I notice that it appears you're not
> testing every supported target, just one target from each architecture.
> For instance, you're not testing and i386 build of the ieee1275 or efi
> platforms. 

Well, if ieee1275 or efi should be tested on i386, I think the testsuite
should enable these tests by default. Although I'm not sure there is x86
hardware which uses OpenFirmware, is there?

> Since you're not using qemu on the non-x86 platforms, I'm not sure if
> testing the various platforms of other architectures would be worth
> while (eg. arm-coreboot and arm-efi). Perhaps someone more
> knowledgeable than I can weight in.

I can also test with QEMU installed if desired for certain architectures.

Maybe you could make a list of target/architecture combinations you want
me to test.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Collecting GRUB 2.06 test results

[Glenn Washburn]

On Thu, 11 Feb 2021 01:18:38 +0100
John Paul Adrian Glaubitz  wrote:

> Hi Glenn!
> 
> On 2/11/21 12:57 AM, Glenn Washburn wrote:
> > Ok, I'm glad you're running the tests on native hardware and in that
> > case I'm not surprised most of the qemu tests aren't running
> > because I assume that qemu is not on most of the non x86 platforms.
> > Perhaps we should have the tests show as SKIPPED when the
> > appropriate qemu binary can not be found.
> 
> OK. I wasn't aware of that.

Looks like I might have been wrong about my assumption that qemu is not
on our other supported architectures. If I'm reading this table
correctly, https://wiki.qemu.org/Documentation/Platforms, it looks like
qemu should be able to virtualize any supported platform for arm,
arm64, mips, powerpc, and sparc. I would guess that debian does build
all the supported qemu architectures for those platforms. That way you
could say run the make check tests on a powerpc host for the arm64
target. This would be a way of testing that GRUB cross-compiled on
powerpc for arm64 could in fact boot on an arm64 machine, and more
generally testing every host + target combinations that we support.

> >>> I'd like to note that it appears that these tests do not perform
> >>> most of the various filesystem tests.
> >>
> >> I ran the tests with "make check" (or "make test"), I did not make
> >> any modifications. If some tests were not run that's because GRUB
> >> does not enable them on the target in question.
> > 
> > That's technically true, but not the whole story. GRUB is not
> > enabling the filesystem tests because you don't have your target
> > environment setup such that the tests will be enabled. The
> > filesystem tests require filesystem tools (eg. e2fsprogs for ext*
> > fs tests). You might try installing the prerequisites needed by the
> > tests, and then seeing if they run.
> 
> I can re-run them with the fsprogs installed. Does that just concern
> e2fsprogs or other filesystems as well?

There's a lot more than e2fsprogs to get all the filesystems being
tested. I'm putting the final touches on a CI system I've made for GRUB
and here's the list of ubuntu packages I install for running the tests.
I think they should be the same for debian.

qemu-system
ovmf
openbios-ppc
openbios-sparc
wamerican
xorriso
locales
language-pack-en
mtools
tar
cpio
gzip
lzop
xz-utils
parted
util-linux
squashfs-tools
zfsutils-linux
dosfstools
exfat-utils
ntfs-3g
e2fsprogs
btrfs-progs
xfsprogs
hfsprogs
jfsutils
reiserfsprogs
udftools
nilfs-tools
f2fs-tools
genromfs
attr

> >> You can see that by looking at the configure.ac. It's basically all
> >> targets that build more than just the utilities.
> > 
> > Great, that's what I was thinking. I notice that it appears you're
> > not testing every supported target, just one target from each
> > architecture. For instance, you're not testing and i386 build of
> > the ieee1275 or efi platforms. 
> 
> Well, if ieee1275 or efi should be tested on i386, I think the
> testsuite should enable these tests by default. Although I'm not sure
> there is x86 hardware which uses OpenFirmware, is there?

GRUB is built for a particular target, which is an architecture,
platform combination. The test suite only runs for the built target. So
if you're not building for multiple targets on the same architecture,
then you're not testing all targets for that architecture. I'm not
familiar with the hardware of most of the targets GRUB supports, but I
do believe that i386-ieee1275 is supported.

> > Since you're not using qemu on the non-x86 platforms, I'm not sure
> > if testing the various platforms of other architectures would be
> > worth while (eg. arm-coreboot and arm-efi). Perhaps someone more
> > knowledgeable than I can weight in.
> 
> I can also test with QEMU installed if desired for certain
> architectures.

I think that would make for better quality test output. On ubuntu I
install qemu-system and get all the right binaries.

> Maybe you could make a list of target/architecture combinations you
> want me to test.

Take a look at the .travis.yml file in the matrix section. You'll see
the variable GRUB_TARGETS defined multiple times, once for each
architecture. GRUB_TARGETS is itself a list of targets. I believe, we
should ideally testing all those targets. In practice, I've had a hard
time getting quite a few of them to work (tests to run properly),
including i386-ieee1275 (haven't found a build of open firmware for
i386 qemu). 

Glenn

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 1/2] efi: SPI NOR flash support

[Michael Lawnick]

Hi,

seven days of silence. In the end no interest for extending EFI support?

KR
Michael

Am 05.02.2021 um 09:58 schrieb Michael Lawnick:

Add EFI SPI NOR driver

Use UEFI interface for accessing SPI NOR flashes.
If supported the implementation of UEFI boot software abstracts
away all those ugly H/W details like SPI controller or protocol.
Provided functions:
grub_efi_spi_nor_
init
erase
write
read
flash_size
flash_id
erase_block_size

This driver might be used for further abstraction to a common
(SPI) flash interface.

Signed-off-by: Michael Lawnick 
---
[Patch v2 1/2] : fix flaw in EFI header, wrong sequence of methods.
---
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 68b9e9f68..4d775e5f6 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -446,7 +446,7 @@ image = {
 i386_pc = boot/i386/pc/boot.S;

 cppflags = '-DHYBRID_BOOT=1';
-
+
 i386_pc_ldflags = '$(TARGET_IMG_LDFLAGS)';
 i386_pc_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x7C00';

@@ -656,6 +656,12 @@ module = {
 enable = i386_multiboot;
   };

+module = {
+  name = efi_spi_nor;
+  common = bus/spi/efi_spi_nor.c;
+  enable = efi;
+};
+
   module = {
 name = nativedisk;
 common = commands/nativedisk.c;
diff --git a/grub-core/bus/spi/efi_spi_nor.c
b/grub-core/bus/spi/efi_spi_nor.c
new file mode 100644
index 0..0e073b436
--- /dev/null
+++ b/grub-core/bus/spi/efi_spi_nor.c
@@ -0,0 +1,298 @@
+/*  efi_spi_nor.c  - Give access to SPI NOR flash through UEFI interface.
+ *  Copyright 2021 Nokia
+ *  Licensed under the GNU General Public License v3.0 only
+ *  SPDX-License-Identifier: GPL-3.0-only
+ *
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2008  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+GRUB_MOD_LICENSE ("GPLv3+");
+
+#define EFI_SPI_NOR_FLASH_PROTOCOL_GUID \
+   { 0xb57ec3fe, 0xf833, 0x4ba6, \
+   {0x85, 0x78, 0x2a, 0x7d, 0x6a, 0x87, 0x44, 0x4b} \
+   }
+
+#define EFI_FLASHID_LEN 3
+
+struct efi_spi_nor_flash_protocol {
+   struct spi_nor  *spi_peripheral;
+   grub_efi_uint32_t   flash_size;
+   grub_efi_uint8_tdevice_id[EFI_FLASHID_LEN];
+   grub_efi_uint32_t   erase_block_size;
+
+   grub_efi_status_t (* get_flash_id)(struct efi_spi_nor_flash_protocol
*this,
+grub_uint8_t *buffer);
+   grub_efi_status_t (* read_data)(struct efi_spi_nor_flash_protocol *this,
+ grub_uint32_t offset, grub_uint32_t 
len, grub_uint8_t *data);
+   grub_efi_status_t (* lf_read_data)(struct efi_spi_nor_flash_protocol
*this,
+grub_uint32_t offset, 
grub_uint32_t len, grub_uint8_t *data);
+   grub_efi_status_t (* read_status)(struct efi_spi_nor_flash_protocol 
*this,
+   grub_uint32_t num_bytes, 
grub_uint8_t *status);
+   grub_efi_status_t (* write_status)(struct efi_spi_nor_flash_protocol
*this,
+grub_uint32_t num_bytes, 
grub_uint8_t *status);
+   grub_efi_status_t (* write_data)(struct efi_spi_nor_flash_protocol 
*this,
+  grub_uint32_t offset, grub_uint32_t 
len, grub_uint8_t *data);
+   grub_efi_status_t (* erase_blocks)(struct efi_spi_nor_flash_protocol
*this,
+grub_uint32_t offset, 
grub_uint32_t blk_count);
+};
+
+/* grub_efi_spi_nor_init - initialize access to SPI NOR flash device
+ *
+ * Search pool of SPI NOR flash devices known to underlying EFI bootware.
+ * Use  and  to filter out devices.
+ *
+ * IN: flash_id - optional, pointer to max 3 bytes
(EFI_FLASHID_LEN) to match against
+ *SPI flash JEDEC ID, use NULL if no filtering.
+ * IN: num_id_bytes - number of bytes in flash_id. Maximum 3 bytes
+ *are used for comparison.
+ * IN: instance - number of device occurances to skip
+ *
+ * returns : pointer to flash device or NULL on failure
+ */
+void *
+grub_efi_spi_nor_init(grub_uint8_t *flash_id, grub_uint32_t
num_id_bytes, grub_uint32_t instance)
+{
+   grub_efi_guid_t efi_guid_

Re: Re: [PATCH v2 1/2] efi: SPI NOR flash support

[Paul Menzel]

Sehr geehrte Damen und Herren,


vielen Dank für Ihre Nachricht, die ich nach dem 12. Februar 2021 lesen werde.


Freundliche Grüße

Paul Menzel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel