X-Original-To: alpine-user@lists.alpinelinux.org Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) by lists.alpinelinux.org (Postfix) with ESMTP id E022AF84F37 for ; Wed, 22 May 2019 10:19:24 +0000 (UTC) Received: by mail-vs1-f43.google.com with SMTP id x8so1040036vsx.13 for ; Wed, 22 May 2019 03:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x4CSFBux7p+A79/D1WAlLMrx7jcFN647eh6UXRrrcVo=; b=FHrPRC0Qk7qRAq7UkYSsHTCEM13YMMB5+elABKhE9u8AKag1+HYoyccc6AIXqgKd0D o5keRFFQFWH5kh56HRruFAGB44S4/m4maRlMbdl54qANEuE2TDGsf4EGKI+NBMTv4lDa MKM41cyD5Cs1BdVZoSR4TdKLPmIOw6B6cGa6uFbPEuLcNwD2JkxO5NGaYdQmBaQxBVbc 0Hb4Dy4M0jfo4GMUtAS14Jtv4Y87Xy6+R9XGvhBsa9tZ4Sb2kgqkyifet2tBgy+a6xYI 2K6AJP4X0KAJiARla2mifgBc+1ynWj3x3EuMlVbo0u56VYReaKc5jjXcNscdLvt7tw+V LHwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x4CSFBux7p+A79/D1WAlLMrx7jcFN647eh6UXRrrcVo=; b=j3t7qmlSDhOOOw6Z0dR9D/oM4rfDKKmIedBXqd8i8jP3ezRSOtbvtrPEW8VevuNxC1 jNWqsVKLNEfbquXlmahK2QR7hhwFxG125iuVUGn3IpWrjL/AAGEzTMmrk/xeecuhJZMU XnP5PlJKFfGwCPWlCFPUnG8yQcN8rmVAefUYFYXv31JRptYI81yj5iGpPztQiXnP3xf4 hV9f66PFgub1Z5uEqOSrymv9KqM7aqGx45E8/XPjBbli7052ZQipYTlqcMp8IQ4YCfVd A+zfXQJ51ABh9oUESh3C4HkzH/F4LacJj33qyuw5Hg44c0Mn7Smx6Q5ltOzT1t53HhTr R4qg== X-Gm-Message-State: APjAAAVE+fH1bHEKPXC7kvKr+iO2qDqc6kTfMGx0NbWsNx9v2lJgaidt +uzLD7LSrmCi10UepB0vN3nNpXdOv2B196m0Wtg= X-Google-Smtp-Source: APXvYqx607Eg6vqEGccrhqmcfXcUmWVXVt/jCrvxX1X17x2Byzj5xwg4qcfWmmquQ+UDrxYAu9P1od3b8HcOiq6/0fc= X-Received: by 2002:a67:6949:: with SMTP id e70mr4454867vsc.217.1558520364291; Wed, 22 May 2019 03:19:24 -0700 (PDT) X-Mailinglist: alpine-user Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 References: <7UaXDB64aA-AKdSpg0glsyp9eC9YXzhavG2ajWEa4clIeZMiQmnl0PSVo7-6KJgSubMK39qT7h29XXqaaatkGkul2eIx2m7wdnfEDRZs80Y=@protonmail.com> <_NI3wuRjIA0NqYSUhsfS60Q2xS0n4-CaxV1iMaTh98LEWNQwKmE8_KVuHVIrWKBjnIvI_-FVSSE50bFdXMqF0bvvZ5jkvWgY66f-Gk9Bx2g=@protonmail.com> In-Reply-To: From: Gee Date: Wed, 22 May 2019 11:19:12 +0100 Message-ID: Subject: Re: [alpine-user] Raspberry Pi Zero can't boot rpi armhf version To: East Cc: Paul Zillmann , alpine-user@lists.alpinelinux.org Content-Type: multipart/alternative; boundary="000000000000b05cdb0589774cbe" --000000000000b05cdb0589774cbe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's great news! Would love to hear what you end up with :-) On Wed, 22 May 2019, 10:12 East, wrote: > I have made a breakthrough. I am not quite sure how yet, but I have gotte= n > Alpine 3.9.2 to boot. I assume that 3.9.4 will also work with this fix, b= ut > I have not tested it yet. > > Because I needed a reference that is relatively similar to Alpine > (Raspbian is not) I downloaded the Arch ARM image for the RPi (I think th= ey > use the same one for all models, I am not sure). Much like Raspbian, they > have the kernel in / as "kernel.img". However, they also store initramfs = in > / as "initramfs-linux.img". The contents of config.txt is as follows: > > gpu_mem=3D64 > initramfs initramfs-linux.img followkernel > > After moving vmlinuz-rpi to ../kernel.img, and moving initramfs-rpi to > ../initramfs-linux.img, I copied and pasted the Arch config.txt contents > into the Alpine one. Magically, it just booted. I have tested this on the > Pi 1/B and Zero. > > There are two possibilities: 1) The raspberry pi "bootloader" (or perhaps > the kernel) expects there to be files with certain names. This is at leas= t > the case for kernel.img. 2) There is some conflict in config.txt that mak= es > everything refuse to boot. > > Maybe it is a combination of these things, maybe it is neither. I am goin= g > to play around with it later today as see what combinations of filenames > and config options result in a bootable system. > > > Sent with ProtonMail Secure Email. > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original = Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 > On Wednesday, May 22, 2019 8:04 AM, Gee wrote: > > For what it's worth, I am seeing this behaviour on a 3B+ as well, but not > with raspbian on the same hardware. > > I'll try some older builds later to see if we're dealing with a regressio= n > or not... > > On Wed, 22 May 2019, 08:25 East, wrote: > >> I apologize if my tone earlier was abrasive. I was frustrated at the tim= e. >> >> I am going to try to figure out how "kernel=3D" should be formatted. I h= ave >> compared it to raspbian, and by default, raspbian does not use that line= at >> all. They simply place the kernel(s) in the / directory, named kernel.im= g >> and kernel7.img. IIRC, the latter is used for the pi 2/3, while the form= er >> is used for 0/1. I have no idea where they keep initramfs. >> >> I have also tested this on a Pi 1/B, (2012 model) with the same result. = I >> do not have any other Pi's laying around on which I can test it, so I ca= n't >> be sure if this issue affects models other than 1B and Zero. >> >> Another theory I had was that this was failing because it had multiple >> partitions. Because I intended to do a sys install, I had one FAT32 and = one >> ext4 partition. I thought there was an off chance it was failing because= it >> couldin't find the right partition. This theory is wrong, because it als= o >> fails with only the FAT32 partition. >> >> >> Sent with ProtonMail Secure Email. >> >> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original= Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 >> On Wednesday, May 22, 2019 12:33 AM, East wrote: >> >> I have read both of those links thoroughly. Neither tell me anything new= . >> >> As I said in one of my other emails, the issue seems to be that it isn't >> reading config.txt. I have tried taking out the model specific condition= als >> and moving the file to ./boot, neither of which have changed anything. I >> have tried making the kernel line an absolute path, I have removing boot= / >> from the front of it (after moving config.txt to /boot), neither of whic= h >> have done anything. If it could read config.txt properly, I wouldn't hav= e >> this problem in the first place. By default, the Alpine image HAS a kern= el >> line in config.txt that points to the correct kernel, it just isn't usin= g >> config.txt for whatever reason. No matter what I change in config.txt, i= t >> seems to have no effect. I know that the file is changing SOME settings, >> because I can enable the rainbow screen and set boot_delay... But the >> kernel lines aren't correctly loading the kernel. >> >> I have also tried doing this with Alpine 3.9.2, because that is the >> version used in [1]. Same problem. >> >> I have also tried moving the kernel to /kernel.img again, and specifying >> the root filesystem in cmdline.txt. It still kernel panics. I have also >> tried specifying the rootfstype as fat32, and rootwait. Neither of them = do >> anything. With only rootfstype=3Dfat32 and root=3D/dev/mmcblk0p1, I also= get a >> register dump and "mmc0: timeout waiting for hardware interrupt". I don'= t >> believe this is relevant. >> >> Because config.txt is being correctly read for SOME of the settings, tha= t >> implies there is some kind of error with the kernel line. >> >> >> Sent with ProtonMail Secure Email. >> >> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original= Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 >> On Tuesday, May 21, 2019 1:35 PM, Paul Zillmann >> wrote: >> >> Hello East, >> >> >> "Kernel panic - not syncing: VFS: Unable to mount root fs on >> unknown-block(0,0)" >> >> suggest that the kernel doesn't know what rootfs to mount nor has any >> modules for that. >> An initramfs would be usefull in that situation - at least to get an >> emergency shell. >> In the config.txt look out for the kernel=3D line (you could also set it= so >> your kernel don't have to be on kernel.img). >> kernel=3Dpath/to/kernel >> initramfs path/to/initramfs >> >> The missing =3D sign is there on purpose! >> >> You could also try ramfsfile=3D and ramfsaddr=3D but I've found no memor= y >> address for the Pi Zero W. Some use 0x00a0000, other use 0x00800000, >> "followkernel" is also a valid address. >> >> You could also create an cmdline.txt which should contain kernel cmd >> paremeters, eg. root=3D/dev/mmcblk0xyz >> >> Please check out this resource and see if it helps: >> https://pi3g.com/2019/01/10/alpine-boot-process-on-the-raspberry-pi/ >> >> Here are some boot parameters for the Pi bootloader: >> https://www.raspberrypi.org/documentation/configuration/config-txt/boot.= md >> >> - Paul >> >> >> Am 21.05.19 um 03:00 schrieb East: >> >> I am starting a new thread here, seeing as my earlier question was >> answered, (thanks Paul). >> >> Based on this >> >> page, I am lead to believe that someone got Alpine working on the Pi Zer= o >> W. The Zero W is basically the same as the RPi Zero, with the only >> difference being the addition of wifi and bluetooth. In that page, it >> sounded like most of the author's problems had to do with wifi, and the >> install worked normally otherwise. So, there is the possibility that >> something changed between 3.9.2 and 3.9.4 that broke the install on RPi >> Zero. >> >> I have been referencing these three pages: >> [1] https://wiki.alpinelinux.org/wiki/Raspberry_Pi_Zero_W_-_Installation >> (linked above) >> [2] https://wiki.alpinelinux.org/wiki/Raspberry_Pi >> [3] >> https://wiki.alpinelinux.org/wiki/Classic_install_or_sys_mode_on_Raspber= ry_Pi >> >> The installation process is basically the same for the first part: simpl= y >> create a FAT32 partition (in [1] and [2]) or FAT16 (in [3]) and extract = the >> tar to it. >> >> [1] recommends setting the following in usercfg.txt: >> gpu_mem=3D16 >> dtparam=3Daudio=3Doff >> dtoverlay=3Dpi3-disable-bt >> dtoverlay=3Dw1-gpio >> enable_uart=3D1 >> >> It also has a section: "Create cache folder and add rng-tools packages". >> I do not believe this section is relevant for this problem. >> >> [2] recommends setting the following in usercfg.txt: >> dtparam=3Daudio=3Don >> disable_overscan=3D1 >> >> [3] recommends this in usercfg.txt: >> enable_uart=3D1 >> >> With the exception of perhaps "enable_uart", I don't think any of these >> settings would prevent the Pi Zero from booting. >> >> I have extracted the tar to both FAT32 and FAT16 partitions. I have trie= d >> setting the boot and lba flags on the partition in gparted. No matter wh= at >> I do, the Pi Zero will not boot. >> >> My theory is that this has something to do with the Pi Zero being unable >> to find the correct kernel. The LED blinks 7 times, pauses, and repeats. >> From here >> : >> "7 flashes: kernel.img not found" >> >> I have tried moving "boot/vmlinuz-rpi" up a directory (to what would be >> the / directory if it were booted instead of mounted on my PC) and renam= ing >> it "kernel.img". When I try booting it that way, I get a kernel panic: >> >> "Kernel panic - not syncing: VFS: Unable to mount root fs on >> unknown-block(0,0)" >> >> This is an improvement, because at least it gives me something other tha= n >> the rainbow screen (which I enabled in config.txt). >> >> Beyond this, I am not sure what I should do. In theory, the Pi Zero >> should parse the config.txt file and locate the correct kernel to load t= hat >> way. I have tried setting "boot_delay=3D1" to no avail. I have also theo= rized >> that it might refuse to boot because I extracted the files from the tar >> using my regular user, and the Pi won't read config.txt unless it is own= ed >> by root. A recursive chgrp/chown has debunked that theory, because even >> after that it still refuses to boot. >> >> I am going to try moving/renaming initramfs as well as the kernel and se= e >> if that changes anything. At the very least, it might be a workaround... >> but if I do that, it will refuse to boot on RPi 2/3. In my case I don't >> care, because I only intend to use this on a Zero, but would be unusable= as >> a long term fix. >> >> >> >> > --000000000000b05cdb0589774cbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's great news! Would love to hear what you end up= with :-)

On Wed, 22 May 2019, 10:12 East, <e4st@protonmail.com> wrote:
I have made a breakthrough. I am not quite sure how yet= , but I have gotten Alpine 3.9.2 to boot. I assume that 3.9.4 will also wor= k with this fix, but I have not tested it yet.

Because I needed a reference that is relatively similar to Alpine (Raspbia= n is not) I downloaded the Arch ARM image for the RPi (I think they use the= same one for all models, I am not sure). Much like Raspbian, they have the= kernel in / as "kernel.img". However, they also store initramfs = in / as "initramfs-linux.img". The contents of config.txt is as f= ollows:

gpu_mem=3D64
initr= amfs initramfs-linux.img followkernel

After mo= ving vmlinuz-rpi to ../kernel.img, and moving initramfs-rpi to ../initramfs= -linux.img, I copied and pasted the Arch config.txt contents into the Alpin= e one. Magically, it just booted. I have tested this on the Pi 1/B and Zero= .

There are two possibilities: 1) The raspberr= y pi "bootloader" (or perhaps the kernel) expects there to be fil= es with certain names. This is at least the case for kernel.img. 2) There i= s some conflict in config.txt that makes everything refuse to boot.

= Maybe it is a combination of these things, maybe it is neither. I am going = to play around with it later today as see what combinations of filenames an= d config options result in a bootable system.


Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90= =E2=80=90=E2=80=90 Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2= =80=90=E2=80=90=E2=80=90
On Wednesday, May 22, 2019 8:04 AM,= Gee <g.plumb@gmail.com> wrote:

For what it's worth, I am seeing this behaviour on a 3B+= as well, but not with raspbian on the same hardware.

I'll try some older builds later to s= ee if we're dealing with a regression or not...
On Wed, 22 May 2019, 08:= 25 East, <e4st@protonmail.com> wrote:
I apologize if my tone earlier was abrasive. I w= as frustrated at the time.

I am going to try t= o figure out how "kernel=3D" should be formatted. I have compared= it to raspbian, and by default, raspbian does not use that line at all. Th= ey simply place the kernel(s) in the / directory, named kernel.img and kern= el7.img. IIRC, the latter is used for the pi 2/3, while the former is used = for 0/1. I have no idea where they keep initramfs.

=
I have also tested this on a Pi 1/B, (2012 model) with the = same result. I do not have any other Pi's laying around on which I can = test it, so I can't be sure if this issue affects models other than 1B = and Zero.

Another theory I had was that this w= as failing because it had multiple partitions. Because I intended to do a s= ys install, I had one FAT32 and one ext4 partition. I thought there was an = off chance it was failing because it couldin't find the right partition= . This theory is wrong, because it also fails with only the FAT32 partition= .


Sent with ProtonMail Secure Email.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80= =90 Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90= =E2=80=90
On Wednesday, May 22, 2019 12:33 AM, East <e4st@protonmail.com> wrote:

I have read both of those links thoroughly. Neither tell me= anything new.

As I said in one of = my other emails, the issue seems to be that it isn't reading config.txt= . I have tried taking out the model specific conditionals and moving the fi= le to ./boot, neither of which have changed anything. I have tried making t= he kernel line an absolute path, I have removing boot/ from the front of it= (after moving config.txt to /boot), neither of which have done anything. I= f it could read config.txt properly, I wouldn't have this problem in th= e first place. By default, the Alpine image HAS a kernel line in config.txt= that points to the correct kernel, it just isn't using config.txt for = whatever reason. No matter what I change in config.txt, it seems to have no= effect. I know that the file is changing SOME settings, because I can enab= le the rainbow screen and set boot_delay... But the kernel lines aren't= correctly loading the kernel.

I ha= ve also tried doing this with Alpine 3.9.2, because that is the version use= d in [1]. Same problem.

I have also= tried moving the kernel to /kernel.img again, and specifying the root file= system in cmdline.txt. It still kernel panics. I have also tried specifying= the rootfstype as fat32, and rootwait. Neither of them do anything. With o= nly rootfstype=3Dfat32 and root=3D/dev/mmcblk0p1, I also get a register dum= p and "mmc0: timeout waiting for hardware interrupt". I don't= believe this is relevant.

Because config.txt = is being correctly read for SOME of the settings, that implies there is som= e kind of error with the kernel line.


Sent with ProtonMail Secure= Email.

=E2=80=90=E2=80=90=E2=80=90=E2= =80=90=E2=80=90=E2=80=90=E2=80=90 Original Message =E2=80=90=E2=80=90=E2=80= =90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Tuesday, May 21, 2= 019 1:35 PM, Paul Zillmann <p.zillmann@h6g.de> wrote:

Hello East,
<= br>

"Kernel panic - not = syncing: VFS: Unable to mount root fs on unknown-block(0,0)"
sugges= t that the kernel doesn't know what rootfs to mount nor has any modules for that.
An initramfs would be usefull in th= at situation - at least to get an emergency shell.
In the config.txt look out for the kerne= l=3D line (you could also set it so your kernel don't have to be on kernel.img).
ke= rnel=3Dpath/to/kernel
initramfs path/to/initramfs

The missing =3D sign is there on purpose!
<= br>
You could also try ramfsfile=3D and ramfsaddr=3D but I've= found no memory address for the Pi Zero W. Some use 0x00a0000, other use 0x00800000, "followkernel" is also a valid address.
=

You could also create an cmdline.txt which should conta= in kernel cmd paremeters, eg. root=3D/dev/mmcblk0xyz

Ple= ase check out this resource and see if it helps: https://pi3g.com/2019/01/10/alpine-boot-process= -on-the-raspberry-pi/

Here are some boot p= arameters for the Pi bootloader: https://www.raspberrypi.org/documentation/configuration/c= onfig-txt/boot.md

- Paul

Am 21.05.19 um 03:00 schrieb East:
I am starting a new thread here, seeing as my ea= rlier question was answered, (thanks Paul).

= Based on this page, I am lead to believe that someone got Alpine working on the Pi Zero W. The Zero W is basically the same as the RPi Zero, with the only difference being the addition of wifi and bluetooth. In that page, it sounded like most of the author's problems had to do with wifi, and the install worked normally otherwise. So, there is the possibility that something changed between 3.9.2 and 3.9.4 that broke the install on RPi Zero.

I have = been referencing these three pages:

The installation process is basicall= y the same for the first part: simply create a FAT32 partition (in [1] and [2]) or FAT16 (in [3]) and extract the tar to it.

<= div>[1] recommends setting the following in usercfg.txt:
gpu_= mem=3D16
dtparam=3Daudio=3Doff
dtoverlay=3Dpi3-= disable-bt
dtoverlay=3Dw1-gpio
enable_uart=3D1<= br>

It also has a section: "Creat= e cache folder and add rng-tools packages". I do not believe this section is relevant for this problem.

[2] recomme= nds setting the following in usercfg.txt:
dtparam=3Daudio=3Do= n
disable_overscan=3D1

[3] recom= mends this in usercfg.txt:
enable_uart=3D1

=
With the exception of perhaps "enable_uart", I don'= ;t think any of these settings would prevent the Pi Zero from booting.

I have extracted the tar to both FAT32 and FAT16 pa= rtitions. I have tried setting the boot and lba flags on the partition in gparted. No matter what I do, the Pi Zero will not boot.
<= div>
My theory is that this has something to do with the= Pi Zero being unable to find the correct kernel. The LED blinks 7 times, pauses, and repeats. From here: "7 fl= ashes: kernel.img not found"

I have tried moving "boot/vmlinuz-rpi" up a directory (to what would be the / directory if it were booted instead of mounted on my PC) and renaming it "kernel.img". When I tr= y booting it that way, I get a kernel panic:

<= /div>
"Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)"

This is= an improvement, because at least it gives me something other than the rainbow screen (which I enabled in config.txt).

Beyond this, I am not sur= e what I should do. In theory, the Pi Zero should parse the config.txt file and locate the correct kernel to load that way. I have tried setting "boot_delay=3D1&= quot; to no avail. I have also theorized that it might refuse to boot because I extracted the files from the tar using my regular user, and the Pi won't read config.txt unless it is owned by root. A recursive chgrp/chown has debunked that theory, because even after that it still refuses to boot.

<= div>I am going to try moving/renaming initramfs as well as the kernel and see if that changes anything. At the very least, it might be a workaround... but if I do that, it will refuse to boot on RPi 2/3. In my case I don't care, because I only intend to use this on a Zero, but would be unusable as a long term fix.



--000000000000b05cdb0589774cbe-- --- Unsubscribe: alpine-user+unsubscribe@lists.alpinelinux.org Help: alpine-user+help@lists.alpinelinux.org ---