X-Original-To: alpine-user@lists.alpinelinux.org Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) by lists.alpinelinux.org (Postfix) with ESMTP id 61C71F84EA4 for ; Wed, 22 May 2019 08:05:00 +0000 (UTC) Received: by mail-vs1-f49.google.com with SMTP id w19so853099vsw.8 for ; Wed, 22 May 2019 01:05:00 -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=DGDd2wci5FyVPnzvMnsnIdP47q9p5l7aPDlaUTqjH9k=; b=Pme6/UcoTh2V+Rb1vtt+Ca89J/bRMWrNLWmK2D+UhjnkETTds+EaDp4mAgN+YML4L7 qkfa++usXMjhJtDvwjYpGrqSlkI9DoRtvjrQIfFqi/JPG7Nsdtdy/XzV5O1t1cLEJ5Yg OxgUu9E4894j4/TL96d9z1FVVyyJgZmj04LfAxw+pOv4Wr/vowzfGOYPixFPkngUfLDZ oTJtBbv/mulcPJoljQN8EBLkqfqUQ1gvt38DLNE8DHS8qP253nMwgEIH6/LJXWA79vZW mq98bPf8ygRQZkEl1GYGW3TeyXsaPx19yJfClOU5MLOzfNWYyY+pi88wCEG/1rVc+Qmw fzfw== 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=DGDd2wci5FyVPnzvMnsnIdP47q9p5l7aPDlaUTqjH9k=; b=iJiSmPIeE5bbFFfJ6HBLzvJejlRbEHsyno8+cB2qNGpYNTa7S7WeorOUtAej5N8rk9 Q01zts1vZqyVtspegd0u3Zw9PZDqA6De2Ozkt+8qjM8OBWbJ/E8i8N3VQ+R2t538M3q4 63a4KUO3Gfjp1svbw9/LzSDaW72/RdZsdtvbB+j1BJM4Az5U1C8cR90lMfiAArwTur4q p0A4LMz7xcMWvKNIOt3DCKrLjbbgGfbOcKWNa9vsha8UWPgMO7CTSyLD/uCLlsSm59Gs lVy8E7fyPy36Mctir5hXh1+/iAvRfgmX0pj0i8o6kX2FUUu079IAdhHUk0qPtZQyeS26 fobA== X-Gm-Message-State: APjAAAXjAZWo0OOj1eYGTR5lmrsP4X0JkRB7cnYEydTzzMDDxW7vDdEz b7xiLYxbWRSRZtVmXk8SfFVue1cVfRGVbnG0qig= X-Google-Smtp-Source: APXvYqwKRRFmvoKuFhZyrLbUi/c7UNVMt1qfFTEMTsi4fh+IQTGU9Pvaaok2pdwMfXQIAZVVoJSKaUvI7IX2oJZ2U44= X-Received: by 2002:a67:6949:: with SMTP id e70mr4159779vsc.217.1558512299642; Wed, 22 May 2019 01:04:59 -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 09:04:44 +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="000000000000ff91eb0589756b18" --000000000000ff91eb0589756b18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 regression or not... On Wed, 22 May 2019, 08:25 East, wrote: > I apologize if my tone earlier was abrasive. I was frustrated at the time= . > > I am going to try to figure out how "kernel=3D" should be formatted. I ha= ve > 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.img > and kernel7.img. IIRC, the latter is used for the pi 2/3, while the forme= r > 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 was failing because it had multiple > partitions. Because I intended to do a sys install, I had one FAT32 and o= ne > 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 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 conditiona= ls > 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 which > have done anything. If it could read config.txt properly, I wouldn't have > this problem in the first place. By default, the Alpine image HAS a kerne= l > 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 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 d= o > 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, that > 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 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 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.m= d > > - 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 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: > [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_Raspberr= y_Pi > > The installation process is basically the same for the first part: simply > create a FAT32 partition (in [1] and [2]) or FAT16 (in [3]) and extract t= he > 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 tried > setting the boot and lba flags on the partition in gparted. No matter wha= t > 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 renami= ng > 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 than > the rainbow screen (which I enabled in config.txt). > > Beyond this, I am not sure what I should do. In theory, the Pi Zero shoul= d > parse the config.txt file and locate the correct kernel to load that way.= I > have tried setting "boot_delay=3D1" to no avail. I have also theorized th= at > 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. > > 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. > > > > --000000000000ff91eb0589756b18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For what it's worth, I am seeing this behaviour on a = 3B+ as well, but not with raspbian on the same hardware.
<= br>
I'll try some older builds later to see if w= e're dealing with a regression or not...

On Wed, 22 May 2019, 08:2= 5 East, <e4st@protonmail.com&= gt; wrote:
I apologize if= my tone earlier was abrasive. I was frustrated at the time.
=
I am going to try to figure out how "kernel=3D" sh= ould be formatted. I have compared it to raspbian, and by default, raspbian= does not use that line at all. They simply place the kernel(s) in the / di= rectory, named kernel.img and kernel7.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 i= nitramfs.

I have also tested this on a P= i 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 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 pa= rtition. This theory is wrong, because it also fails with only the FAT32 pa= rtition.


Se= nt 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&g= t; wrote:

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

As I said in one of my other emails, the issue seems to be that it isn= 9;t reading config.txt. I have tried taking out the model specific conditio= nals 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 which= have done anything. If it could read config.txt properly, I wouldn't h= ave this problem in the first place. By default, the Alpine image HAS a ker= nel 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.tx= t, it seems to have no effect. I know that the file is changing SOME settin= gs, because I can enable the rainbow screen and set boot_delay... But the k= ernel lines aren't correctly loading the kernel.
I have also tried doing this with Alpine 3.9.2, because t= hat is the version used in [1]. Same problem.

=
I have also tried moving the kernel to /kernel.img again, and sp= ecifying the root filesystem in cmdline.txt. It still kernel panics. I have= also tried specifying the rootfstype as fat32, and rootwait. Neither of th= em do anything. With only rootfstype=3Dfat32 and root=3D/dev/mmcblk0p1, I a= lso get a register dump and "mmc0: timeout waiting for hardware interr= upt". 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.
<= br>

Sent with ProtonMail Secu= re 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,


"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-ras= pberry-pi/

Here are some boot parameters f= or the Pi bootloader: http= s://www.raspberrypi.org/documentation/configuration/config-txt/boot.md<= br>

- Paul


=
Am 21.05.19 um 03:00 sc= hrieb East:
I am starting a new thr= ead here, seeing as my earlier question was answered, (thanks Paul).

= Based on this p= age, 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 basically 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 flashes: kernel.img not found"

I ha= ve 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.


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