... and the last published snapshot is Build20170831. This may be related.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab(a)suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hello,
I will receive my rock64 board soon.
https://www.pine64.org/?page_id=7147
I would like to run some openSUSE on it. There are no upstream support
but lets see what we could do.
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi,
I am trying to run
openSUSE-Tumbleweed-ARM-JeOS-efi.armv7l-2017.10.29-Build1.7.raw
using qemu.
When I use qemu-system-aarch64 with 64-bit UEFI code
aavmf-aarch64-code.bin then the only I see is the EFI console:
UEFI Interactive Shell v2.287477C2-69C7-11D2-8E39-00A0C969723B B8F1C820
EDK IIlProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA B8F1FF18
UEFI v2.60 (EDK II, 0x00010000)008-7F9B-4F30-87AC-60C9FEF5DA4E B8348710
Mapping table
FS0: Alias(s):HD1a0b:;BLK2:
VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)
BLK5: Alias(s):
VenHw(F9B94AE2-8BA6-409B-9D56-B9B417F53CB3)
BLK0: Alias(s):
VenHw(8047DB4B-7E9C-4C0C-8EBC-DFBBAACACE8F)
BLK1: Alias(s):
VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)
BLK3: Alias(s):
VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(2,GPT,3DF8DD35-94BC-4FF0-B74C-12853D4B1811,0x65000,0x83004)
BLK4: Alias(s):
VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(3,GPT,38C4AA8C-4A7F-49C4-BCFD-6C2C755496BD,0xE8800,0x3DE781)
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
FSOpen: Open '\startup.nsh' Success
FSOpen: Open '\startup.nsh' Success
FSOpen: Open '\startup.nsh' Success
Shell> bootarm
FSOpen: Open '\efi\boot\bootarm.EFI' Success
FSOpen: Open '\efi\boot\bootarm.EFI' Success
FSOpen: Open '\efi\boot\bootarm.EFI' Success
FSOpen: Open '\efi\boot\bootarm.EFI' Success
[Security] 3rd party image[0] can be loaded after EndOfDxe:
VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)/\efi\boot\bootarm.EFI.
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B B8EDE440
Unloading driver at 0x00000000000
Shell> Error Status: Unsupported (line number 1)
As far as I understand, 64-bit Qemu UEFI code doesn't expect to see and
run 32-bit EFI executable.
When I try to use qemu-uefi-aarch32.bin as firmware, then I see the
following:
Initialization of device cfi.pflash01 failed: failed to read the initial
flash content
As far as I understand, qemu-uefi-aarch32.bin is in wrong format, but
there are no other files in ovfm rpm package.
What is the proper way to run JeOS-efi.armv7? Is it supposed to work in
qemu?
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
We have written a minimal kernel interrupt handler for the Raspberry
Pi 3. It is running the current 64-bit Tumbleweed kernel. I am curious
about the rate of interrupts that we might be able to capture.
The ISR does little other than run when a raising edge interrupt
happens. We are looking at /proc/interrupts to see how many interrupts
have happened.
We see that at around 23 kHz we begin to loose interrupts. The system
is not doing anything else.
Does that seem reasonable? I have not seen any good discussion of
this. I think it is rather low. I am guessing that the issue is how
the Linux kernel responds to interrupts. The housework in setting
things up so that the interrupt can run must be the resource hog.
Opinions? Suggestions?
--
Roger Oberholtzer
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hello,
yesterday I finally got my 14'' Pinebook [1].
There is Ubuntu 16.04 MATE as a default OS, but I would like to use
openSUSE TW on it of course.
So, I found raw.xz XFCE-image for aarch64 [2] and used this command
"to burn" image on the microSD card:
# unxz -c openSUSE-Tumbleweed-ARM-XFCE-efi.aarch64-2017.06.10-Build2.3.raw.xz
| sudo dd of=/dev/mmcblk1p
No success.
Pinebook tried to boot from microSD card, but... it seems that there
is something wrong with bootloader.
Here [3] I found this command:
# xzcat openSUSE-Tumbleweed-ARM-XFCE-efi.aarch64-2017.06.10-Build2.3.raw.xz
| dd bs=4M of=/dev/ mmcblk1p oflag=sync
Exactly the same... image is there, echo $? tells 0, but pinebook ignore it.
Image on microSD card is marked as a bootable. I checked it with parted(8).
I asked Google and it showed me this [4]. This is HOWTO for fedora 21
on Cubietruck, but there is one interesting thing: step (4) Write
U-Boot to Media.
Do we also need to install bootloader extra? Because, as I said, for
me it seems like a bootloader problem. If yes, where is this script or
documentation about it?
Also I would ask about rootfs-images. Do we have some
information/HOWTOs about these?
Cheers,
Alex
[1] https://www.pine64.org/?page_id=3707
[2] http://download.opensuse.org/ports/aarch64/tumbleweed/images/openSUSE-Tumbl…
[3] https://en.opensuse.org/HCL:AArch64_EFI
[4] https://kashyapc.fedorapeople.org/arm/installing-Fedora-21-on-microSD-card-…
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi Daniel,
Let's move the discussion to opensuse-arm list.
Am 23.11.2017 um 12:07 schrieb Daniel Molkentin:
> On 11/22/2017 06:31 PM, Andreas Färber wrote:
>> Am 22.11.2017 um 04:25 schrieb Dominique Leuenberger:
>>> ==== kernel-source ====
>>> Version update (4.13.12 -> 4.14.0)
>>> Subpackages: kernel-default kernel-default-devel kernel-devel kernel-docs kernel-macros kernel-syms
>>>
>>> - Update to 4.14-final.
>> On the aarch64 based Pine64 board it has been observed that the updated
>> dtb-allwinner package now requires the axp20x-regulator module in the
>> initrd for using the MMC driver, and its parent module axp20x-rsb does
>> not get loaded automatically even if added to the initrd.
> I would prefer if that would be fixed in the kernel by adding the proper
> dependencies.
> Is there any chance for that?
There's multiple issues at play here:
1) This is not a module compile-time dependency issue, but rather a
run-time dependency issue, which AFAIU dracut is not resolving today.
As a result the JeOS images in openSUSE:Factory:ARM etc. contain a
number of add_drivers entries to load such extra modules:
https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM/JeOS/conf…
That is of course ugly and would be nice to get resolved differently.
Dracut would need to parse the Device Tree in /sys/firmware/ to discover
what regulator, clock, power domain, etc. nodes are being referenced,
then read their "compatible" strings and resolve them to the modules to
add. The kernel uses generic API calls such as clk_get() and
regulator_get(), thus no compile-time dependency for e.g. mmc modules.
However when updating from 4.13 to 4.14 or from 4.14-rc4 to -rc8 it
would've still read the current Device Tree and not discovered this new
dependency for next boot. And Kiwi images get built in KVM, which will
have a different Device Tree than the user's system or even ACPI. So I
don't see a full solution yet.
Let me know if I should report this somewhere upstream - it didn't seem
a distro-specific issue for our Bugzilla.
https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_troubleshoo…
explains what info to include in a bug report, but not actually where to
file it. ;) No link on dracut.wiki.kernel.org either.
2) axp20x-rsb driver does have MODULE_DEVICE_TABLE(of, ...), so it is
unclear to me why the DT -> module resolution for auto-loading is not
working here.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri…
It is almost certainly an upstream kernel issue, possibly in sunxi-rsb
bus driver. Stefan has already reported this on #linux-sunxi.
> Otherwise, the "proper" dracut patch would
> looks something like the attached one.
Hm, instmod is just the equivalent of "add_drivers", is it? That would
not be enough here. Also not all ARM systems need this driver, it's an
extra chip on some boards only.
What you could do is more generally add all =drivers/mfd drivers. But if
we keep adding drivers by category instead of addressing the underlying
discovery issue, we risk at some point the initrd getting too large for
low-RAM systems.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
2017-10-22 9:31 GMT+03:00 Rick Ashford <Rick.Ashford(a)suse.com>:
> There is a great thread on the Armbian forum about the EspressoBin, and it
> helped me get things up and running with Tumbleweed.
>
> One of the guys there has a public Dropbox link that includes their images
> for flashing the u-boot loader:
> https://www.dropbox.com/sh/kmgmo1uubhcczx5/AAAYEvTIFxpBr0dHG2QcapTza?dl=0
>
> The thread:
> https://forum.armbian.com/index.php?/topic/4089-espressobin-support-develop…
>
> With their boot loader I was able to finally use BTRFS images as well as PXE
> boot. It also has an EFI load function in the help that I need to get around
> to trying.
Well, If armian u-boot is able to boot our standard EFI-Grub JeOS,
then we can recommend to use it with openSUSE and don't reinvent the
wheel.
>
> Rick Ashford
> Sales Engineering Manager - West
> SUSE Linux
> rick.ashford(a)suse.com
> Office: 512-782-4318
> Mobile: 512-731-3035
>
> On Oct 21, 2017, at 12:32 PM, Matwey V. Kornilov <matwey.kornilov(a)gmail.com>
> wrote:
>
> 2017-10-21 19:47 GMT+03:00 Matwey V. Kornilov <matwey.kornilov(a)gmail.com>:
>
> 2017-10-21 19:35 GMT+03:00 Matwey V. Kornilov <matwey.kornilov(a)gmail.com>:
>
> 2017-10-20 18:02 GMT+03:00 Matwey V. Kornilov <matwey.kornilov(a)gmail.com>:
>
> 2017-10-20 17:37 GMT+03:00 Alexander Graf <agraf(a)suse.de>:
>
>
>
> On 20.10.17 16:21, Matwey V. Kornilov wrote:
>
> 20.10.2017 17:12, Alexander Graf пишет:
>
>
>
> On 20.10.17 13:57, Matwey V. Kornilov wrote:
>
> Hi,
>
>
> I've just received EspressoBin 1G. Any success stories how to run openSUSE?
>
>
>
> I think you'll basically have to somehow flash a working U-Boot with
>
> distro boot onto it and then just dd the tumbleweed/42.3 iso onto a usb
>
> stick and cross your fingers that gets you to a point where you can
>
> install :)
>
>
> It has microsd card, I think it should be able to boot from sd, no?
>
> I also need to to find serial console pins on the board :)
>
>
> There seems to be a lengthy discussion on the mailing list. I guess you
>
> can select the boot device using DIP switches though?
>
>
> Yes, I can. I think it is preferred way. Need to find expected layout
>
> to place u-boot image.
>
>
> Well, at least while booting from SATA, they say that BootRom looks
>
> for code starting with zero offset, which implies that there can not
>
> be any GPT partition table.
>
> Probably, it is similar for SD. If so, we need to flash our EFI-aware
>
> u-boot instead of upstream one.
>
>
>
> Well, SATA flash image from here
>
>
> http://wiki.espressobin.net/tiki-index.php?page=Boot+ESPRESSObin+from+SATA+…
>
>
> suits for booting from microsd card, when it is flushed from zero
>
> offset and boot selection switchs are set to 7.
>
>
> At least, there is non-destructive way to check out u-boot image.
>
>
> Double checked. Seems that microsd boot doesn't work and is not
> supported. At least for my V5 board.
> It just falls back to SPINOR
>
>
>
>
> http://espressobin.net/forums/topic/how-to-flash-u-boot/
>
>
>
> Alex
>
>
>
>
> --
>
> With best regards,
>
> Matwey V. Kornilov
>
>
>
>
> --
>
> With best regards,
>
> Matwey V. Kornilov
>
>
>
>
> --
>
> With best regards,
>
> Matwey V. Kornilov
>
>
>
>
> --
> With best regards,
> Matwey V. Kornilov
> --
> To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
> To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
>
>
--
With best regards,
Matwey V. Kornilov
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Am 22.11.2017 um 04:25 schrieb Dominique Leuenberger:
> ==== kernel-source ====
> Version update (4.13.12 -> 4.14.0)
> Subpackages: kernel-default kernel-default-devel kernel-devel kernel-docs kernel-macros kernel-syms
>
> - Update to 4.14-final.
> - commit c152297
> - rpm/kernel-binary.spec.in: rename kGraft to KLP (fate#323682)
> - commit 0ed191d
On the aarch64 based Pine64 board it has been observed that the updated
dtb-allwinner package now requires the axp20x-regulator module in the
initrd for using the MMC driver, and its parent module axp20x-rsb does
not get loaded automatically even if added to the initrd.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/a…
Workaround is to add to your /etc/dracut.conf.d/sunxi_modules.conf:
force_drivers+=" axp20x-rsb "
and (if after the update) to re-run dracut by, e.g., mkinitrd.
Without such an initrd change it will wait indefinitely for the root
partition on SD card on next boot.
Selecting an older kernel in GRUB will not help - only manually loading
an older dtb in U-Boot can help (if e.g. you had multiversion enabled).
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Recently I tried to use all Tumbleweed images on my three Raspberry Pi's (1B,
2B, and 3B). I did not experience problems with booting the image. Also
upgrading to the newest version works OK.
After that I tried to generate a third party package from GitHub, SBFspot, om
my Raspberry Pi 2B. Generating means a.o. compiling a C++ module.
The compiler produced a fatal internal error, which I reported on bugzilla.
https://bugzilla.opensuse.org/show_bug.cgi?id=1068967
I would not expect such an error from a compiler. Should I report this error
also somewhere upstream? If, yes, where?
--
fr.gr.
Freek de Kruijf
member openSUSE
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi,
I tried openSUSE-Tumbleweed-ARM-XFCE-chromebook.armv7l-2017.07.22-Build1.1
recently, but it just beeps and kicks me back to the boot screen
immediately. No messages on screen, partition resizing, etc.
Any hints? Some cgpt magic I could try from ChromeOS perhaps?
Best regards, --D.
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org