Hi!
...unfortunately, 2.6.27 contains the 'reset floating' bug, and from
the point 'reset floating' is fixed, to 2.6.28-rc1, tree will not
compile, so bisect is quite hard to do. Any ideas?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Friday, 31 of October 2008, Pavel Machek wrote:
> Hi!
>
> ...unfortunately, 2.6.27 contains the 'reset floating' bug, and from
> the point 'reset floating' is fixed, to 2.6.28-rc1, tree will not
> compile, so bisect is quite hard to do. Any ideas?
Is this a regression from .27?
Rafael
> On Friday, 31 of October 2008, Pavel Machek wrote:
> > Hi!
> >
> > ...unfortunately, 2.6.27 contains the 'reset floating' bug, and from
> > the point 'reset floating' is fixed, to 2.6.28-rc1, tree will not
> > compile, so bisect is quite hard to do. Any ideas?
>
> Is this a regression from .27?
Yes, it is (*).
Pavel
(*) Okay, so 2.6.27 does not boot due to the 'reset floating'
bug. 'reset floating' is fixed in 2.6.28-rc1, and compilation of spitz
is fixed in 2.6.28-rc2, but it still will not boot.
So yes, some new spitz-breaking bug got introduced. But no, 2.6.27
will not boot due to other bug. 2.6.26 boots.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, Nov 03, 2008 at 11:40:35AM +0100, Pavel Machek wrote:
> > On Friday, 31 of October 2008, Pavel Machek wrote:
> > > Hi!
> > >
> > > ...unfortunately, 2.6.27 contains the 'reset floating' bug, and from
> > > the point 'reset floating' is fixed, to 2.6.28-rc1, tree will not
> > > compile, so bisect is quite hard to do. Any ideas?
> >
> > Is this a regression from .27?
>
> Yes, it is (*).
> Pavel
> (*) Okay, so 2.6.27 does not boot due to the 'reset floating' bug.
I wouldn't say that was a bug. That was by design of Dmitry, which
I'm far from happy with. If an output is being used to drive a
reset line, you always want to actively drive it to the inactive
state for noise immunity reasons.
> 'reset floating' is fixed in 2.6.28-rc1, and compilation of spitz
> is fixed in 2.6.28-rc2, but it still will not boot.
Compilation errors are only going to get worse as ARM continues to
diversify. We're entirely reliant on sfr's linux-next project to
find build errors prior to merging, and it is unfortunate that this
time around, sfr was on vacation on the run up to the merge window.
Hence, there was very little build coverage of the changes that
went in during this last merge window. I spent most of the merge
window fixing up all the shitty patches that people had submitted up
until that point that either broke compilation or had runtime
problems.
> So yes, some new spitz-breaking bug got introduced. But no, 2.6.27
> will not boot due to other bug. 2.6.26 boots.
If 2.6.27 doesn't boot even with the reset fixes applied, there's a hell
of a lot of changes that could be the culpret (and I don't remember much
that happened before this last merge window.) The only thing I can
suggest is to bisect with the reset fixes on top.
This is precisely where we're let down by not having a Zaurus maintainer
who knows the Zaurus issues inside out, and regularly puts effort into
building and testing kernels for these platforms. That's a hint for
anyone who's reading this.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
> On Mon, Nov 03, 2008 at 11:40:35AM +0100, Pavel Machek wrote:
> > > On Friday, 31 of October 2008, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > ...unfortunately, 2.6.27 contains the 'reset floating' bug, and from
> > > > the point 'reset floating' is fixed, to 2.6.28-rc1, tree will not
> > > > compile, so bisect is quite hard to do. Any ideas?
> > >
> > > Is this a regression from .27?
> >
> > Yes, it is (*).
> > (*) Okay, so 2.6.27 does not boot due to the 'reset floating' bug.
>
> I wouldn't say that was a bug. That was by design of Dmitry, which
> I'm far from happy with. If an output is being used to drive a
> reset line, you always want to actively drive it to the inactive
> state for noise immunity reasons.
Well, if it breaks boot on the machine, I think it is fair to call it
a "bug" :-).
> > 'reset floating' is fixed in 2.6.28-rc1, and compilation of spitz
> > is fixed in 2.6.28-rc2, but it still will not boot.
>
> Compilation errors are only going to get worse as ARM continues to
> diversify. We're entirely reliant on sfr's linux-next project to
> find build errors prior to merging, and it is unfortunate that this
> time around, sfr was on vacation on the run up to the merge window.
> Hence, there was very little build coverage of the changes that
> went in during this last merge window. I spent most of the merge
> window fixing up all the shitty patches that people had submitted up
> until that point that either broke compilation or had runtime
> problems.
:-(.
> > So yes, some new spitz-breaking bug got introduced. But no, 2.6.27
> > will not boot due to other bug. 2.6.26 boots.
>
> If 2.6.27 doesn't boot even with the reset fixes applied, there's a hell
No, 2.6.27 _does_ boot with reset fixes applied. (But it needs those
reset fixes to boot -- that was what I was trying to say).
> of a lot of changes that could be the culpret (and I don't remember much
> that happened before this last merge window.) The only thing I can
> suggest is to bisect with the reset fixes on top.
With the reset & compilation fixes on top... and I'll have to search
for the small patch that fixes the compilation :-((.
If you have any idea what should I try to revert between 2.6.27 and
2.6.28-rc2, that would be helpful... bisect is not completely trivial here.
> This is precisely where we're let down by not having a Zaurus maintainer
> who knows the Zaurus issues inside out, and regularly puts effort into
> building and testing kernels for these platforms. That's a hint for
> anyone who's reading this.
I don't think I have enough time to really maintain Zauruses... but I
can try to help with some testing. So -next is the place that should
get more testing...?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Fri 2008-10-31 16:06:01, Pavel Machek wrote:
> Hi!
>
> ...unfortunately, 2.6.27 contains the 'reset floating' bug, and from
> the point 'reset floating' is fixed, to 2.6.28-rc1, tree will not
> compile, so bisect is quite hard to do. Any ideas?
It is still there in -rc3... And yes, it is a regression from 2.6.27.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
2008/11/5 Pavel Machek <[email protected]>:
> On Fri 2008-10-31 16:06:01, Pavel Machek wrote:
>> Hi!
>>
>> ...unfortunately, 2.6.27 contains the 'reset floating' bug, and from
>> the point 'reset floating' is fixed, to 2.6.28-rc1, tree will not
>> compile, so bisect is quite hard to do. Any ideas?
>
> It is still there in -rc3... And yes, it is a regression from 2.6.27.
Would you be so nice to provide a boot log of 2.6.28-rc3 with
CONFIG_DEBUG_DRIVER enabled?
Thank you.
--
With best wishes
Dmitry
On Wed 2008-11-05 18:13:19, Dmitry wrote:
> 2008/11/5 Pavel Machek <[email protected]>:
> > On Fri 2008-10-31 16:06:01, Pavel Machek wrote:
> >> Hi!
> >>
> >> ...unfortunately, 2.6.27 contains the 'reset floating' bug, and from
> >> the point 'reset floating' is fixed, to 2.6.28-rc1, tree will not
> >> compile, so bisect is quite hard to do. Any ideas?
> >
> > It is still there in -rc3... And yes, it is a regression from 2.6.27.
>
> Would you be so nice to provide a boot log of 2.6.28-rc3 with
> CONFIG_DEBUG_DRIVER enabled?
I'd love to, but it fails with black screen :-(. (But I guess I should
mention that I'm using kexec...)
Do you have "good" config for spitz I could try? (Similar
configuration worked in 2.6.27, but maybe it is a config difference?)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
2008/11/5 Pavel Machek <[email protected]>:
> On Wed 2008-11-05 18:13:19, Dmitry wrote:
>> 2008/11/5 Pavel Machek <[email protected]>:
>> > On Fri 2008-10-31 16:06:01, Pavel Machek wrote:
>> >> Hi!
>> >>
>> >> ...unfortunately, 2.6.27 contains the 'reset floating' bug, and from
>> >> the point 'reset floating' is fixed, to 2.6.28-rc1, tree will not
>> >> compile, so bisect is quite hard to do. Any ideas?
>> >
>> > It is still there in -rc3... And yes, it is a regression from 2.6.27.
>>
>> Would you be so nice to provide a boot log of 2.6.28-rc3 with
>> CONFIG_DEBUG_DRIVER enabled?
>
> I'd love to, but it fails with black screen :-(. (But I guess I should
> mention that I'm using kexec...)
>
> Do you have "good" config for spitz I could try? (Similar
> configuration worked in 2.6.27, but maybe it is a config difference?)
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Try disabling TOUCHSCREEN_CORGI, and enabling SPI, PXA2XX_SPI, HWMON, MAX1111.
Please post your .config anyway.
Do you have anything on the serial console, btw?
--
With best wishes
Dmitry
On Thu 2008-11-06 02:00:35, Dmitry wrote:
> 2008/11/5 Pavel Machek <[email protected]>:
> > On Wed 2008-11-05 18:13:19, Dmitry wrote:
> >> 2008/11/5 Pavel Machek <[email protected]>:
> >> > On Fri 2008-10-31 16:06:01, Pavel Machek wrote:
> >> >> Hi!
> >> >>
> >> >> ...unfortunately, 2.6.27 contains the 'reset floating' bug, and from
> >> >> the point 'reset floating' is fixed, to 2.6.28-rc1, tree will not
> >> >> compile, so bisect is quite hard to do. Any ideas?
> >> >
> >> > It is still there in -rc3... And yes, it is a regression from 2.6.27.
> >>
> >> Would you be so nice to provide a boot log of 2.6.28-rc3 with
> >> CONFIG_DEBUG_DRIVER enabled?
> >
> > I'd love to, but it fails with black screen :-(. (But I guess I should
> > mention that I'm using kexec...)
> >
> > Do you have "good" config for spitz I could try? (Similar
> > configuration worked in 2.6.27, but maybe it is a config difference?)
>
> Try disabling TOUCHSCREEN_CORGI, and enabling SPI, PXA2XX_SPI, HWMON, MAX1111.
> Please post your .config anyway.
DOes not boot for me, either :-(... black screen. config attached.
Could I get your config?
> Do you have anything on the serial console, btw?
I do not have serial cable :-(,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi,
> I do not have serial cable :-(,
Okay I have one that works for sl5500, it needs external power on
sl-cxxx but it should be easy to fix.
--
metan
Well, IIRC spitz still needs the patch to change the vmlinux.ld.S.
Did you guys ever try that?
On Fri, Nov 7, 2008 at 3:14 AM, Cyril Hrubis <[email protected]> wrote:
> Hi,
>> I do not have serial cable :-(,
>
> Okay I have one that works for sl5500, it needs external power on
> sl-cxxx but it should be easy to fix.
>
> --
> metan
>
On Fri 2008-11-07 21:23:41, Eric Miao wrote:
> Well, IIRC spitz still needs the patch to change the vmlinux.ld.S.
> Did you guys ever try that?
I never heard about that patch, do you have it handy?
Pavel
> On Fri, Nov 7, 2008 at 3:14 AM, Cyril Hrubis <[email protected]> wrote:
> > Hi,
> >> I do not have serial cable :-(,
> >
> > Okay I have one that works for sl5500, it needs external power on
> > sl-cxxx but it should be easy to fix.
> >
> > --
> > metan
> >
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
2008/11/7 Pavel Machek <[email protected]>:
> On Fri 2008-11-07 21:23:41, Eric Miao wrote:
>> Well, IIRC spitz still needs the patch to change the vmlinux.ld.S.
>> Did you guys ever try that?
>
> I never heard about that patch, do you have it handy?
http://rpsys.net/openzaurus/patches/archive/pxa-linking-bug.patch
I plan to submit a bit modified version of this patch later.
>
> Pavel
>
>> On Fri, Nov 7, 2008 at 3:14 AM, Cyril Hrubis <[email protected]> wrote:
>> > Hi,
>> >> I do not have serial cable :-(,
>> >
>> > Okay I have one that works for sl5500, it needs external power on
>> > sl-cxxx but it should be easy to fix.
>> >
>> > --
>> > metan
>> >
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
--
With best wishes
Dmitry
On Fri, Nov 07, 2008 at 05:57:33PM +0300, Dmitry wrote:
> 2008/11/7 Pavel Machek <[email protected]>:
> > On Fri 2008-11-07 21:23:41, Eric Miao wrote:
> >> Well, IIRC spitz still needs the patch to change the vmlinux.ld.S.
> >> Did you guys ever try that?
> >
> > I never heard about that patch, do you have it handy?
>
> http://rpsys.net/openzaurus/patches/archive/pxa-linking-bug.patch
>
> I plan to submit a bit modified version of this patch later.
That doesn't look like something that should be accepted. Take a moment
to put some thought into the question. Why should we _allocate_ and
contain the stack in the resulting image? Does the stack contain any
data that must be pre-initialized?
Obviously not.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Fri, 2008-11-07 at 18:23 +0000, Russell King wrote:
> On Fri, Nov 07, 2008 at 05:57:33PM +0300, Dmitry wrote:
> > 2008/11/7 Pavel Machek <[email protected]>:
> > > On Fri 2008-11-07 21:23:41, Eric Miao wrote:
> > >> Well, IIRC spitz still needs the patch to change the vmlinux.ld.S.
> > >> Did you guys ever try that?
> > >
> > > I never heard about that patch, do you have it handy?
> >
> > http://rpsys.net/openzaurus/patches/archive/pxa-linking-bug.patch
> >
> > I plan to submit a bit modified version of this patch later.
>
> That doesn't look like something that should be accepted. Take a moment
> to put some thought into the question. Why should we _allocate_ and
> contain the stack in the resulting image? Does the stack contain any
> data that must be pre-initialized?
>
> Obviously not.
Firstly, I don't think that patch should ever make it into a mainline
kernel. I can perhaps give some clues why its required though. I think
the bootloader on the zaurus truncates the image when writing the kernel
into flash using the standard flashing process. By having that much
extra padding on the end of the kernel, nothing important is lost.
How did the original 2.4 kernels ever work? Binutils used to be buggy
and left this padding in. Nobody therefore ever noticed the bug in the
bootloader.
The above theory is guesswork based on the kernels I've seen work and
not work and I wrote the patch mentioned above as a workaround a long
time ago and more pressing issues meant I never got back to it. I'd love
to see someone work out the problem for sure!
Cheers,
Richard
2008/11/8 Richard Purdie <[email protected]>:
>
> On Fri, 2008-11-07 at 18:23 +0000, Russell King wrote:
>> On Fri, Nov 07, 2008 at 05:57:33PM +0300, Dmitry wrote:
>> > 2008/11/7 Pavel Machek <[email protected]>:
>> > > On Fri 2008-11-07 21:23:41, Eric Miao wrote:
>> > >> Well, IIRC spitz still needs the patch to change the vmlinux.ld.S.
>> > >> Did you guys ever try that?
>> > >
>> > > I never heard about that patch, do you have it handy?
>> >
>> > http://rpsys.net/openzaurus/patches/archive/pxa-linking-bug.patch
>> >
>> > I plan to submit a bit modified version of this patch later.
>>
>> That doesn't look like something that should be accepted. Take a moment
>> to put some thought into the question. Why should we _allocate_ and
>> contain the stack in the resulting image? Does the stack contain any
>> data that must be pre-initialized?
>>
>> Obviously not.
>
> Firstly, I don't think that patch should ever make it into a mainline
> kernel. I can perhaps give some clues why its required though. I think
> the bootloader on the zaurus truncates the image when writing the kernel
> into flash using the standard flashing process. By having that much
> extra padding on the end of the kernel, nothing important is lost.
>From what I do understand from updater.sh, the kernel is fully written to nand.
Otherwise there will be lot's more problems. Maybe w/o padding the image is
loaded too high? Can't verify ATM.
BTW: Since I'm away from my zaurii for few days, can one please send
me the whole
ROM (I mean the one at CS0, not NAND) image of any Zaurus device?
> How did the original 2.4 kernels ever work? Binutils used to be buggy
> and left this padding in. Nobody therefore ever noticed the bug in the
> bootloader.
>
> The above theory is guesswork based on the kernels I've seen work and
> not work and I wrote the patch mentioned above as a workaround a long
> time ago and more pressing issues meant I never got back to it. I'd love
> to see someone work out the problem for sure!
I did rewrote your patch in a bit cleaner way (to apply the hack to
vmlinux.lds.in
in a cleaner way and only on PXA_SHARPSL), however I'm not submitting it
till I find what's the real reason for this problem.
--
With best wishes
Dmitry
On Sun, Nov 09, 2008 at 02:12:47AM +0300, Dmitry wrote:
> 2008/11/8 Richard Purdie <[email protected]>:
> > Firstly, I don't think that patch should ever make it into a mainline
> > kernel. I can perhaps give some clues why its required though. I think
> > the bootloader on the zaurus truncates the image when writing the kernel
> > into flash using the standard flashing process. By having that much
> > extra padding on the end of the kernel, nothing important is lost.
...
>
> I did rewrote your patch in a bit cleaner way (to apply the hack to
> vmlinux.lds.in
> in a cleaner way and only on PXA_SHARPSL), however I'm not submitting it
> till I find what's the real reason for this problem.
Even if the reason is found, I don't think it's something that should
concern the kernel, especially as there is a script which writes the
kernel image into the flash. If it's a case that the boot loader needs
an extra 4K tacked on the end of the kernel image, that should be easy
enough for this 'updater.sh' shell script to do.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
2008/11/9 Russell King <[email protected]>:
> On Sun, Nov 09, 2008 at 02:12:47AM +0300, Dmitry wrote:
>> 2008/11/8 Richard Purdie <[email protected]>:
>> > Firstly, I don't think that patch should ever make it into a mainline
>> > kernel. I can perhaps give some clues why its required though. I think
>> > the bootloader on the zaurus truncates the image when writing the kernel
>> > into flash using the standard flashing process. By having that much
>> > extra padding on the end of the kernel, nothing important is lost.
> ...
>>
>> I did rewrote your patch in a bit cleaner way (to apply the hack to
>> vmlinux.lds.in
>> in a cleaner way and only on PXA_SHARPSL), however I'm not submitting it
>> till I find what's the real reason for this problem.
>
> Even if the reason is found, I don't think it's something that should
> concern the kernel, especially as there is a script which writes the
> kernel image into the flash. If it's a case that the boot loader needs
> an extra 4K tacked on the end of the kernel image, that should be easy
> enough for this 'updater.sh' shell script to do.
Actually on my tosa builds it's like 40k of zeroes (.bss is before .stack and so
is also present in the zImage). It seems that just 4k of padding isn't enough
(I tried that).
>
> --
> Russell King
> Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
> maintainer of:
>
--
With best wishes
Dmitry
On Sun, Nov 09, 2008 at 02:25:35AM +0300, Dmitry wrote:
> 2008/11/9 Russell King <[email protected]>:
> > On Sun, Nov 09, 2008 at 02:12:47AM +0300, Dmitry wrote:
> >> 2008/11/8 Richard Purdie <[email protected]>:
> >> > Firstly, I don't think that patch should ever make it into a mainline
> >> > kernel. I can perhaps give some clues why its required though. I think
> >> > the bootloader on the zaurus truncates the image when writing the kernel
> >> > into flash using the standard flashing process. By having that much
> >> > extra padding on the end of the kernel, nothing important is lost.
> > ...
> >>
> >> I did rewrote your patch in a bit cleaner way (to apply the hack to
> >> vmlinux.lds.in
> >> in a cleaner way and only on PXA_SHARPSL), however I'm not submitting it
> >> till I find what's the real reason for this problem.
> >
> > Even if the reason is found, I don't think it's something that should
> > concern the kernel, especially as there is a script which writes the
> > kernel image into the flash. If it's a case that the boot loader needs
> > an extra 4K tacked on the end of the kernel image, that should be easy
> > enough for this 'updater.sh' shell script to do.
>
> Actually on my tosa builds it's like 40k of zeroes (.bss is before .stack
> and so is also present in the zImage). It seems that just 4k of padding
> isn't enough (I tried that).
That doesn't change my view - it's something that the kernel shouldn't be
caring about. And as I point out, this script can add the padding itself
which seems to be the right place to resolve the problem.
(and I've finally dropped that bad email address from the CC line.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Fri 2008-11-07 17:57:33, Dmitry wrote:
> 2008/11/7 Pavel Machek <[email protected]>:
> > On Fri 2008-11-07 21:23:41, Eric Miao wrote:
> >> Well, IIRC spitz still needs the patch to change the vmlinux.ld.S.
> >> Did you guys ever try that?
> >
> > I never heard about that patch, do you have it handy?
>
> http://rpsys.net/openzaurus/patches/archive/pxa-linking-bug.patch
>
> I plan to submit a bit modified version of this patch later.
Could you send me full .config that is known to work?
Do I need pxa-linking-bug.patch to get it to boot?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sun 2008-11-09 12:45:45, Pavel Machek wrote:
> On Fri 2008-11-07 17:57:33, Dmitry wrote:
> > 2008/11/7 Pavel Machek <[email protected]>:
> > > On Fri 2008-11-07 21:23:41, Eric Miao wrote:
> > >> Well, IIRC spitz still needs the patch to change the vmlinux.ld.S.
> > >> Did you guys ever try that?
> > >
> > > I never heard about that patch, do you have it handy?
> >
> > http://rpsys.net/openzaurus/patches/archive/pxa-linking-bug.patch
> >
> > I plan to submit a bit modified version of this patch later.
>
> Could you send me full .config that is known to work?
>
> Do I need pxa-linking-bug.patch to get it to boot?
(Note that I'm booting using kexec, not sharp bootloader).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
2008/11/9 Pavel Machek <[email protected]>:
> On Sun 2008-11-09 12:45:45, Pavel Machek wrote:
>> On Fri 2008-11-07 17:57:33, Dmitry wrote:
>> > 2008/11/7 Pavel Machek <[email protected]>:
>> > > On Fri 2008-11-07 21:23:41, Eric Miao wrote:
>> > >> Well, IIRC spitz still needs the patch to change the vmlinux.ld.S.
>> > >> Did you guys ever try that?
>> > >
>> > > I never heard about that patch, do you have it handy?
>> >
>> > http://rpsys.net/openzaurus/patches/archive/pxa-linking-bug.patch
>> >
>> > I plan to submit a bit modified version of this patch later.
>>
>> Could you send me full .config that is known to work?
>>
>> Do I need pxa-linking-bug.patch to get it to boot?
>
> (Note that I'm booting using kexec, not sharp bootloader).
It seems that neither kexec, nor qemu require pxa-linking-bug.patch
Attached a .config that I use for testing. It contains all sharp zaurii
selected, however you can easily deselect unnecessary ones.
--
With best wishes
Dmitry
On Sun 2008-11-09 15:30:17, Dmitry wrote:
> 2008/11/9 Pavel Machek <[email protected]>:
> > On Sun 2008-11-09 12:45:45, Pavel Machek wrote:
> >> On Fri 2008-11-07 17:57:33, Dmitry wrote:
> >> > 2008/11/7 Pavel Machek <[email protected]>:
> >> > > On Fri 2008-11-07 21:23:41, Eric Miao wrote:
> >> > >> Well, IIRC spitz still needs the patch to change the vmlinux.ld.S.
> >> > >> Did you guys ever try that?
> >> > >
> >> > > I never heard about that patch, do you have it handy?
> >> >
> >> > http://rpsys.net/openzaurus/patches/archive/pxa-linking-bug.patch
> >> >
> >> > I plan to submit a bit modified version of this patch later.
> >>
> >> Could you send me full .config that is known to work?
> >>
> >> Do I need pxa-linking-bug.patch to get it to boot?
> >
> > (Note that I'm booting using kexec, not sharp bootloader).
>
> It seems that neither kexec, nor qemu require pxa-linking-bug.patch
>
> Attached a .config that I use for testing. It contains all sharp zaurii
> selected, however you can easily deselect unnecessary ones.
It should still boot on spitz, right? I'd rather not touch that
.config...
Thanks!
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
2008/11/9 Pavel Machek <[email protected]>:
> On Sun 2008-11-09 15:30:17, Dmitry wrote:
>> 2008/11/9 Pavel Machek <[email protected]>:
>> > On Sun 2008-11-09 12:45:45, Pavel Machek wrote:
>> >> On Fri 2008-11-07 17:57:33, Dmitry wrote:
>> >> > 2008/11/7 Pavel Machek <[email protected]>:
>> >> > > On Fri 2008-11-07 21:23:41, Eric Miao wrote:
>> >> > >> Well, IIRC spitz still needs the patch to change the vmlinux.ld.S.
>> >> > >> Did you guys ever try that?
>> >> > >
>> >> > > I never heard about that patch, do you have it handy?
>> >> >
>> >> > http://rpsys.net/openzaurus/patches/archive/pxa-linking-bug.patch
>> >> >
>> >> > I plan to submit a bit modified version of this patch later.
>> >>
>> >> Could you send me full .config that is known to work?
>> >>
>> >> Do I need pxa-linking-bug.patch to get it to boot?
>> >
>> > (Note that I'm booting using kexec, not sharp bootloader).
>>
>> It seems that neither kexec, nor qemu require pxa-linking-bug.patch
>>
>> Attached a .config that I use for testing. It contains all sharp zaurii
>> selected, however you can easily deselect unnecessary ones.
>
> It should still boot on spitz, right? I'd rather not touch that
> .config...
It boots under qemu spitz emulation. No real HW of SL-CXX00 yet :(
--
With best wishes
Dmitry
> 2008/11/9 Pavel Machek <[email protected]>:
> > On Sun 2008-11-09 12:45:45, Pavel Machek wrote:
> >> On Fri 2008-11-07 17:57:33, Dmitry wrote:
> >> > 2008/11/7 Pavel Machek <[email protected]>:
> >> > > On Fri 2008-11-07 21:23:41, Eric Miao wrote:
> >> > >> Well, IIRC spitz still needs the patch to change the vmlinux.ld.S.
> >> > >> Did you guys ever try that?
> >> > >
> >> > > I never heard about that patch, do you have it handy?
> >> >
> >> > http://rpsys.net/openzaurus/patches/archive/pxa-linking-bug.patch
> >> >
> >> > I plan to submit a bit modified version of this patch later.
> >>
> >> Could you send me full .config that is known to work?
> >>
> >> Do I need pxa-linking-bug.patch to get it to boot?
> >
> > (Note that I'm booting using kexec, not sharp bootloader).
>
> It seems that neither kexec, nor qemu require pxa-linking-bug.patch
>
> Attached a .config that I use for testing. It contains all sharp zaurii
> selected, however you can easily deselect unnecessary ones.
Ugh, that one took quite a while to compile. Fortunately, this one
actually boots... (up to "launching init", anyway)... so the problem
seems to be config-dependend.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html