Hi!
I guess Andrea wanted me to forward this
- Forwarded message from Andrea Adami -
Date: Mon, 1 Feb 2010 13:08:44 +0100
From: Andrea Adami
To: pa...@ucw.cz
Subject: About kernel decompressors
Pavel,
I'd like to add a couple of observations in the "Uncompressing broken
with comm
It sounds to me like this is because of the 1.4M (cannot
remember the exact size) constraint of the kernel size
on NAND that the bootloader is able to load?
On Mon, Feb 1, 2010 at 8:14 PM, Pavel Machek wrote:
> Hi!
>
> I guess Andrea wanted me to forward this
>
> - Forwarded message from
>> 3) kernel size is uninfluent: I tested 930KiB-lzma kernels and 1240KiB
>> gzip-kernels.
>It sounds to me like this is because of the 1.4M (cannot
>remember the exact size) constraint of the kernel size
>on NAND that the bootloader is able to load?
Unfortunately not :(
Kernel did not exceed th
On Tue, Feb 2, 2010 at 1:07 AM, Andrea Adami wrote:
>>> 3) kernel size is uninfluent: I tested 930KiB-lzma kernels and 1240KiB
>>> gzip-kernels.
>
>>It sounds to me like this is because of the 1.4M (cannot
>>remember the exact size) constraint of the kernel size
>>on NAND that the bootloader is a
On Mon 2010-02-01 18:07:01, Andrea Adami wrote:
> >> 3) kernel size is uninfluent: I tested 930KiB-lzma kernels and 1240KiB
> >> gzip-kernels.
>
> >It sounds to me like this is because of the 1.4M (cannot
> >remember the exact size) constraint of the kernel size
> >on NAND that the bootloader is
Again on this:
chatting with Eric about the pxa-linking-bug-r1 patch, it seems it is
needed because of a bug in updater.sh:
Same was reported here:
http://www.oesf.org/index.php?title=SL-C3000_Updater_Script
## Bug in Sharp bit
## o
On Tue, Feb 2, 2010 at 2:15 AM, Pavel Machek wrote:
> On Mon 2010-02-01 18:07:01, Andrea Adami wrote:
>> >> 3) kernel size is uninfluent: I tested 930KiB-lzma kernels and 1240KiB
>> >> gzip-kernels.
>>
>> >It sounds to me like this is because of the 1.4M (cannot
>> >remember the exact size) const
>>>
>>> Back to compressors, I say it must be the commit e7db7b427 because
>>> kernel 2.6.33-rc4 was booting just fine.
>>
>> Report regression to rjw and patch author (cc l-k), then, and get the
>> patch reverted.
>
> Pavel,
>
> Please hold on for a while. Andrea may have some more comments?
>
YE
This is the correct version
>>> I'd say it must be the commit e7db7b427 because
>>> kernel 2.6.33-rc3 was booting just fine on corgi.
2.6.33-rc3 has been tested on spitz by other devs (JaMa and pwgen)
Ok, my last doubt is I only tested on corgi.
Anybody tested flashing newer rc on spitz?
The co
Well, please wait a bit more before reporting...
Eric, with 'fixed' updater.sh I could flash linux-kexecboot 2.6.33-rc6
and it boots!
Still experimenting around.
I'll report later.
TIA
Andrea
___
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo
OMG... we can even avoid that pxa-linking-bug-r1 patch!
2.6.33-rc6 boots vanilla.
[more after LZMA testing]
Andrea
___
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
On Tue, Feb 2, 2010 at 3:22 AM, Andrea Adami wrote:
> OMG... we can even avoid that pxa-linking-bug-r1 patch!
> 2.6.33-rc6 boots vanilla.
>
That really depends - I have several kernel images that can be loaded
without problem, but note size and alignment do look relevant.
> [more after LZMA test
-- Forwarded message --
From: Andrea Adami
Date: Mon, Feb 1, 2010 at 10:48 PM
Subject: Re: [Zaurus-devel] About kernel decompressors (fwd)
To: Eric Miao
>> [more after LZMA testing]
LZMA -> zImage-kexecboot-2.6.32+2.6.33-rc6-r2-c7x0.bin
│ 922084│Feb 1 22:37
This baby is booti
Well, I tested this patch on c7x0 and got two results:
1) we can avoid the pxa-linking-bug-r1 patch
2) we can boot 2.6.33-r6 (and some older too :)
Unexplicable (for me) unalignement issues...thx to Eric Miao for the hint!
I propose therefore to fix the updater.sh and fork the new minimal one
fr
14 matches
Mail list logo
