Your message dated Sun, 9 May 2021 21:57:34 +0200
with message-id <yjg+rut37tm5p...@eldamar.lan>
and subject line Re: Bug#827557: linux-image-4.6.0-1-armmp-lpae: 4.6 armmp
kernel fails to boot on nvidia jetson (4.5 works)
has caused the Debian Bug report #827557,
regarding linux-image-4.6.0-1-armmp-lpae: 4.6 armmp kernel fails to boot on
nvidia jetson (4.5 works)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
827557: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827557
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-image-4.6.0-1-armmp-lpae
Version: 4.6.1-1
Severity: normal
I installed an nvidia jetson board (armhf, v7) with the stretch alpha6
installer. It all worked nicely.
See documentation at:
https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TK1
On upgrading the kernel to 'current testing', (
linux-image-4.6.0-1-armmp-lpae 4.6.1-1, and linux-image-armmp-lpae
4.6+74, from what's in alpha6 installer (
linux-image-4.5.0-2-armmp-lpae 4.5.3-2 and linux-image-armmp-lpae
4.5+73) causes the machine to no longer boot.
I failed to keep a log, but after
[ 3.266688] mmc0: Unknown controller version (3). You may experience
problems.
[ 3.314162] mmc1: Unknown controller version (3). You may experience
problems.
(which appears on successful boots too)
I just get messages about failing to set up IO for a sound device (3
lots), then it hangs.
On the working 4.5 boot I see:
----------------
[ 15.714061] r8169 0000:01:00.0: firmware: failed to load
rtl_nic/rtl8168g-2.fw (-2)
Debian GNU/Linux stretch/sid debian-jetson ttyS0
debian-jetson login:
--------------
I tried to turn extra debug on and failed.
I am about to go on hols for 3 weeks so filing this bug as a
placeholder in case anyone else has info to add.
Clearly further investigation is needed to find out where it is going
wrong.
-- System Information:
Debian Release: 8.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
Hi,
On Thu, Jul 21, 2016 at 04:04:51AM +0100, Wookey wrote:
> On 2016-07-19 11:40 -0700, Martin Michlmayr wrote:
>
> > I tracked it down to CONFIG_ARM_TEGRA_DEVFREQ which I enabled in
> > 4.6-1~exp2.
> >
> > With this module enabled, I see the same hang you do. Without the
> > module, it works.
> >
> > Interestingly, it depends on the version of u-boot used, though.
> > With the u-boot from Debian (i.e. a current mainline DENX u-boot), I
> > do not get this issue (which is why my tests before enabling the
> > module didn't find it). I only see it with the old u-boot from
> > NVIDIA.
> >
> > I brought this up upstream:
> > http://permalink.gmane.org/gmane.linux.ports.tegra/26941
> > and the response was that if mainline u-boot works, I should use that.
> >
> > I then edited the Debian wiki to remove the portions about the old
> > u-boot and made it clear users have to upgrade to Debian's u-boot.
> >
> > IMHO it should be ok to tell users to use a modern mainline u-boot,
> > but I don't mind disabling CONFIG_ARM_TEGRA_DEVFREQ again either
> > if you think that's a good idea.
>
> OK. I've confirmed that. (and that programing the debian uboot needs
> the old R19.3 flash tools, otherwise it just makes the board totally
> dead). So yes, as it all works with the Debian bits and we've
> documented the wrinkles on
> https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TK1 I guess
> that's OK, although it is likely to catch some people out if they
> aren't reading that page.
>
> It would be good to work out the runes for flashing just the uboot
> with lower-level tools, and automating the setting of the uboot runes
> as much as possible.
>
> I guess we can call this bug closed, as it's not the kernel that's at fault.
Okay, doing so now (after some years ;-)).
Regards,
Salvatore
--- End Message ---
