Moving Linux kernel to 4.9

[Penthux]

Unless you know what you are doing and have very good reason to, you are better off letting the firmware decide where to load the initrd:

Code: Select all

initramfs initrd.gz followkernel

Note also the new, preferred syntax ("initramfs <file> <addr>"), although the old version is still supported.

Ok PhilE, I think I know what I'm doing. If not somebody has made a monumentous mistake somewhere along the line.

So, you guys wanted to know if there were any problems or issues and I found some. I'm already aware of the new syntax for loading the ramfsfile, but have been using the older syntax for quite a few years. I tried both versions and all variants in trying to get the initrd to load on the rpi1, 2 and 3. It might be better for Raspbian to load the initrd straight after the kernel with the code you advise but... I'm not working with Raspbian.

[PhilE]

It might be better for Raspbian to load the initrd straight after the kernel with the code you advise but... I'm not working with Raspbian.

From Documentation/initrd.txt (in the kernel source tree):

Code: Select all

When using initrd, the system typically boots as follows:

  1) the boot loader loads the kernel and the initial RAM disk
  2) the kernel converts initrd into a "normal" RAM disk and
     frees the memory used by initrd

This means that after step 2 it doesn't matter where initrd initially was, and since the kernel runs before any distribution-specific code, my advice still applies to you.

[Penthux]

It might be better for Raspbian to load the initrd straight after the kernel with the code you advise but... I'm not working with Raspbian.

From Documentation/initrd.txt (in the kernel source tree):

Code: Select all

When using initrd, the system typically boots as follows:

  1) the boot loader loads the kernel and the initial RAM disk
  2) the kernel converts initrd into a "normal" RAM disk and
     frees the memory used by initrd

This means that after step 2 it doesn't matter where initrd initially was, and since the kernel runs before any distribution-specific code, my advice still applies to you.

I load the initrd at 0xa00000 because the size of my kernels were always changing and I wanted to keep it well out of the way. It's always worked in years gone by and still works now with the 'next' and rpi-4.9.y' branches on the RPi1 but not on the Rpi2 or Rpi3. The problems I'm experiencing were still applicable at 07:30am this morning. Have you fixed them yet?

[PhilE]

We're not going to "fix" something until it is confirmed that there is a problem. Please try with "followkernel" and report back.

[Penthux]

We're not going to "fix" something until it is confirmed that there is a problem. Please try with "followkernel" and report back.

Ok, Sir. As you wish. What exactly do you want me to try with "followkernel", just the RPi2 and Rpi 3 or do you also want me to include and compare results with the RPi1 as well ?

[PhilE]

I suggest you use it on all platforms, but I'm not asking you specifically test it on Pi1.

I assume the initrd.gz you are trying on Pi2/Pi3 is built specifically for Pi2/Pi3, not the same one you use on Pi1?

[Penthux]

I suggest you use it on all platforms, but I'm not asking you specifically test it on Pi1.

I assume the initrd.gz you are trying on Pi2/Pi3 is built specifically for Pi2/Pi3, not the same one you use on Pi1?

The initrd I build is specific to the model of Pi, be it 1, 2 or 3. As is the kernel.

The initrd holds the Slackware ARM minirootfs/installer which the SARPi project use in their images.

[PhilE]

To save time, can you point me at build instructions for the initrd?

[Penthux]

To save time, can you point me at build instructions for the initrd?

No. If you don't know how to build an initrd I haven't got the time to teach you. Sorry. Google for it.

The thing is, if i switch firmware from 'next' branch to 'master' branch the same initrd loads and works like a charm. "followkernel" is what you've asked for so "followkernel" is what you'll get. I'll keep you posted.

[PhilE]

I want to build the same initramfs as you have so that the test is representative - although the build mechanism is the same the content will vary. Presumably you are following some SARPI/Slackware build instructions, so it shouldn't be too arduous to give me a link.

[PhilE]

On a Pi3, a fresh 4.9 kernel loaded on top of BRANCH=next firmware with "initramfs initrd.gz followkernel" boots OK for me:

Code: Select all

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.2-v7+ (phil@buildbot) (gcc version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) ) #59 SMP Wed Jan 11 17:08:51 GMT 2017
[    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt:Machine model: Raspberry Pi 3 Model B Rev 1.2
[    0.000000] cma: Reserved 8 MiB at 0x3a800000
...
[    0.226587] Trying to unpack rootfs image as initramfs...
[    0.675308] Freeing initrd memory: 5224K (aeae6000 - af000000)

However, if I specify the load address using "initramfs initrd.gz 0xa00000" I get:

Code: Select all

[    0.000000] INITRD: 0x00a00000+0x00519e7b overlaps in-use memory region - disabling initrd

Are you convinced yet?

[Penthux]

Are you convinced yet?

Where are you getting those kernels from... rpi-update by any chance?

[Penthux]

I want to build the same initramfs as you have so that the test is representative - although the build mechanism is the same the content will vary. Presumably you are following some SARPI/Slackware build instructions, so it shouldn't be too arduous to give me a link.

http://mirrors.slackware.com/slackware/ ... DME.initrd

I'm using scripts which automate the task of building the initrd. I'm about as likely to share them with you as you are to make your firmware open source.

<edit> I'm going test using "followkernel" as you asked. Then I will get back to you... ... ...

[Penthux]

On a Pi3, a fresh 4.9 kernel loaded on top of BRANCH=next firmware with "initramfs initrd.gz followkernel" boots OK for me:

However, if I specify the load address using "initramfs initrd.gz 0xa00000" I get:

Code: Select all

[    0.000000] INITRD: 0x00a00000+0x00519e7b overlaps in-use memory region - disabling initrd

Are you convinced yet?

HAHAH OK! Yes I'm convinced. 100%. As you said, "initramfs initrd.gz followkernel" loads the initrd on the RPi3 as expected. Using a $LOADADDR is not required. So I guess my old methods are now obsolete.

What threw me is the fact that the RPi 1 boots and loads the initrd using the old syntax, but it also boots using the new syntax - "initramfs initrd.gz followkernel". Whereas the RPi2 and RPi3 only load the initrd using the new syntax, and not with using the old syntax. I thought the RPi devices would be the same across the board in all aspects, but today this dog has learned new tricks. Your advice has enabled me to solve a few other problems too. Thanks, PhilE.

[PhilE]

It's not the syntax that makes the difference, it's the load address. You could achieve the same effect using the old syntax and specifying a load address of 0, which the firmware will interpret as meaning "after the kernel" - "followkernel" is just syntactic sugar.

I suspect the reason the Pi1 kernel works with the initramfs at 0xa00000 is is that it is slightly smaller. If you were curious you could try lowering that address a bit to see how close to the wire it is currently. Alternatively raise the address for Pi2/3 until it does work. The 4.9 kernels must have grown just enough to push it over the edge, so I doubt you would have to change the address by much in either direction to change a success to a failure and vice-versa.

[rpdom]

I suspect the reason the Pi1 kernel works with the initramfs at 0xa00000 is is that it is slightly smaller. If you were curious you could try lowering that address a bit to see how close to the wire it is currently. Alternatively raise the address for Pi2/3 until it does work.

I think it would have to be at least 0xaeae6000, as that is where your followkernel reported the initramfs as having been loaded

Code: Select all

[    0.675308] Freeing initrd memory: 5224K (aeae6000 - af000000)

[PhilE]

No - followkernel actually causes it to be loaded as high as possible within certain limits, but we are trying to establish a lower-bound.

[rpdom]

Oops, misread the number of digits following the 0xa

[RidingTheFlow]

I've just tried to update to 4.9 and my Pi 3 stopped booting. I suspect USB boot stopped working (I boot from Sandisk Extreme USB flash drive since my SD card died).

It powers on, green LED blinks briefly, flash drive blinks briefly and then nothing - just black screen. After couple minutes, rainbow screen comes up and stays like this forever.

When I reverted to my original kernel I've configured USB boot with (4.4.17-v7+), it boots and works ok again.

[DougieLawson]

I've just spent way too long trying to get my 3B with RPF display booting from a USB stick.

With the latest BRANCH=next rpi-update to d34f352899fd567988e2156f97ab5d525f504a88 that one did not want to boot (solid hang at the rainbow splash screen). So I went back to the previous commit I was running bcc6146e102d85b1aa214855ad7aae278d3bd26 to get the Raspberry booted. I'll look at the intervening commits tomorrow as it's a bit late right now..

[RidingTheFlow]

Confirmed, I've updated to bcc6146e102d85b1aa214855ad7aae278d3bd26 (4.9.0) and it booted and seem to work fine, unlike head (4.9.2)

[dom]

Confirmed, I've updated to bcc6146e102d85b1aa214855ad7aae278d3bd26 (4.9.0) and it booted and seem to work fine, unlike head (4.9.2)

I suspect this was caused by latest commit, but we need to confirm that. Can you test this:
https://github.com/Hexxeh/rpi-firmware/ ... a99f1552bc

[asavah]

Confirmed, I've updated to bcc6146e102d85b1aa214855ad7aae278d3bd26 (4.9.0) and it booted and seem to work fine, unlike head (4.9.2)

I suspect this was caused by latest commit, but we need to confirm that. Can you test this:
https://github.com/Hexxeh/rpi-firmware/ ... a99f1552bc

Yep, this one works here, both USB and PXE are able to boot fine.

[RidingTheFlow]

Confirmed, I've updated to bcc6146e102d85b1aa214855ad7aae278d3bd26 (4.9.0) and it booted and seem to work fine, unlike head (4.9.2)

I suspect this was caused by latest commit, but we need to confirm that. Can you test this:
https://github.com/Hexxeh/rpi-firmware/ ... a99f1552bc

Yes, this one boots and works fine.
Edit: head now fixed too.

[shige3106]

Hello, all.

I'm happy to know that raspi2/3 will be available to the kernel 4.8.x and 4.9.x
with sudo BRANCH=next rpi-update

Could you let me know the availaility of TCG TPM driver below ?

------------------
linux/drivers/char/tpm/

tpm_tis.c
tpm_tis_spi.c
tpm_tis_core.c
tpm_tis_core.h
------------------
If it can work,
Do I need to do some additional work to use the driver ?

Regards,
Shige