This is from the cloned bug but belongs here.
Am 18.05.21 um 08:31 schrieb Heinrich Schuchardt:
The original problem report showed the following situation was hit:
common/malloc_simple.c:29:
log_err("alloc space exhausted\n");
You cannot expect normal system behavior when reaching this
Processing control commands:
> clone 975490 -1
Bug #975490 [u-boot-sunxi] u-boot-sunxi: Booting the system got stuck after
"Starting kernel ..."
Bug 975490 cloned as bug 988217
> retitle -1 bootefi causes boot failure with boot.scr
Bug #988217 [u-boot-sunxi] u-boot-sunxi: Bootin
Control: clone 975490 -1
Control: retitle -1 bootefi causes boot failure with boot.scr
Control: tags -1 + fixed-upstream
Control: tags -1 + patch
Control: severity -1 important
On 2021-04-16, Bastian Germann wrote:
> On a Lamobo R1, I can verify 2021.01 versions not to boot with a
> default
On Fri, 16 Apr 2021 17:06:37 +0200 Bastian Germann
wrote:
> The issue is fixed in 2021.04 (experimental) which has the same default
environment as 2021.01.
The upstream commit that fixed this is
https://github.com/u-boot/u-boot/commit/82d01f04facef1276cede067efd02d2a731ffe83
It applies
Am 16.04.21 um 14:25 schrieb Bastian Germann:
The issue is fixed in 2021.04 (experimental) which has the same default
environment as 2021.01.
The upstream commit that fixed this is
https://github.com/u-boot/u-boot/commit/82d01f04facef1276cede067efd02d2a731ffe83
It applies cleanly on
On 2021-04-16, Bastian Germann wrote:
> On Wed, 10 Feb 2021 09:37:01 +0100 Ivo De Decker wrote:
>> > With a locally built version of 2020.10+dfsg-2, I can no longer
>> > reproduce this issue at all.
>> >
>> > Could you try with the new version?
>>
>> Testing/unstable now has version
On Wed, 10 Feb 2021 09:37:01 +0100 Ivo De Decker wrote:
On Mon, Jan 04, 2021 at 08:27:51PM -0800, Vagrant Cascadian wrote:
> >> I'll test on a few of my systems to see if I can reproduce the issue.
> >
> > I can confirm similar behavior on a pinebook, although the kernel does
> > boot and
Hi,
On Mon, Jan 04, 2021 at 08:27:51PM -0800, Vagrant Cascadian wrote:
> >> I'll test on a few of my systems to see if I can reproduce the issue.
> >
> > I can confirm similar behavior on a pinebook, although the kernel does
> > boot and actually load, and eventually displays on the LCD display
On 2020-11-27, Vagrant Cascadian wrote:
> On 2020-11-22, Vagrant Cascadian wrote:
>> On 2020-11-22, Benedikt Spranger wrote:
>>> after a fresh install of Debian "bullseye" the first reboot got stuck
>>> after "Starting kernel ..."
> ...
>>> U-Boot 2020.10+dfsg-1+b1 (Nov 19 2020 - 03:18:11 +)
On Fri, 27 Nov 2020 18:34:13 -0800
Vagrant Cascadian wrote:
> On 2020-11-23, Benedikt Spranger wrote:
> > On Sun, 22 Nov 2020 14:34:33 -0800
> > Vagrant Cascadian wrote:
>
> > U-Boot 2020.10+dfsg-1 (Oct 05 2020 - 19:13:28 +) Allwinner
> > Technology
> ...
> > Found U-Boot script /boot.scr
On 2020-11-22, Vagrant Cascadian wrote:
> On 2020-11-22, Benedikt Spranger wrote:
>> after a fresh install of Debian "bullseye" the first reboot got stuck
>> after "Starting kernel ..."
...
>> U-Boot 2020.10+dfsg-1+b1 (Nov 19 2020 - 03:18:11 +) Allwinner
>> Technology
...
>> Scanning mmc
On 2020-11-23, Benedikt Spranger wrote:
> On Sun, 22 Nov 2020 14:34:33 -0800
> Vagrant Cascadian wrote:
> U-Boot 2020.10+dfsg-1 (Oct 05 2020 - 19:13:28 +) Allwinner
> Technology
...
> Found U-Boot script /boot.scr
> 2417 bytes read in 1 ms (2.3 MiB/s)
> ## Executing script at 4fc0
>
On Sun, 22 Nov 2020 14:34:33 -0800
Vagrant Cascadian wrote:
> Thanks for the bug report...
You're welcome!
> Very surprising that extlinux would work but boot.scr would not; they
> almost certainly use the same load addresses...
I was astonished.
> This symptom is sometimes related to the
Processing control commands:
> found 975490 2020.10+dfsg-1+b1
Bug #975490 [u-boot-sunxi] u-boot-sunxi: Booting the system got stuck after
"Starting kernel ..."
Marked as found in versions u-boot/2020.10+dfsg-1.
--
975490: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975490
Debian Bug
Control: found 975490 2020.10+dfsg-1+b1
Control: version 975490 2020.10+dfsg-1+b1
Thanks for the bug report...
On 2020-11-22, Benedikt Spranger wrote:
> after a fresh install of Debian "bullseye" the first reboot got stuck
> after "Starting kernel ..."
>
> It turend out that booting the system got always stuck using the a
> "normal"
Package: u-boot-sunxi
Severity: critical
Dear Maintainer,
after a fresh install of Debian "bullseye" the first reboot got stuck
after "Starting kernel ..."
It turend out that booting the system got always stuck using the a
"normal" u-boot boot sequence. Using extlinux or FIT-Images is not
17 matches
Mail list logo
