Re: vt8500-kernel doesn't boot on Flytouch 256M
Paul Sokolovsky
On Mon, 23 May 2011 09:35:21 +0400
Alexey Charkov <alc...@gmail.com> wrote:
> Hello Paul!
>
> 2011/5/23 Paul Sokolovsky <pmi...@gmail.com>:
> > Hello Alexey,
> >
> > FYI. I finally had a chance to try your kernel on my Flytouch tablet
> > (WM8505). I used wmt_defconfig and the resulting kernel doesn't
> > boot for me (u-boot is used on this tablet).
> > https://github.com/projectgus/kernel_wm8505 kernel boots fine. I
> > also tried to disable all machines except MACH_WM8505_7IN_NETBOOK,
> > but got the same result.
>
> Thanks for the report! Could you please check whether this is related
> to machine id detection (via earlyprintk and serial console)? Or,
> could you please post the contents of your SCC_ID register (physical
> MMIO address 0xd8120000, u32)?
Well, I don't have a serial cable, and I figure earlyprintk wouldn't
print to a raw framebuffer. Otherwise:
# ./devmem2 0xd8120000 w
/dev/mem opened.
Memory mapped at address 0x40001000.
Value at address 0xD8120000 (0x40001000): 0x34260103
Which matches the value in head-vt8500.S
>
> Thanks,
> Alexey
--
Best regards,
Paul mailto:pmi...@gmail.com
Alexey Charkov
> Hello,
>
> On Mon, 23 May 2011 09:35:21 +0400
> Alexey Charkov <alc...@gmail.com> wrote:
>
>> Hello Paul!
>>
>> 2011/5/23 Paul Sokolovsky <pmi...@gmail.com>:
>> > Hello Alexey,
>> >
>> > FYI. I finally had a chance to try your kernel on my Flytouch tablet
>> > (WM8505). I used wmt_defconfig and the resulting kernel doesn't
>> > boot for me (u-boot is used on this tablet).
>> > https://github.com/projectgus/kernel_wm8505 kernel boots fine. I
>> > also tried to disable all machines except MACH_WM8505_7IN_NETBOOK,
>> > but got the same result.
>>
>> Thanks for the report! Could you please check whether this is related
>> to machine id detection (via earlyprintk and serial console)? Or,
>> could you please post the contents of your SCC_ID register (physical
>> MMIO address 0xd8120000, u32)?
>
> Well, I don't have a serial cable, and I figure earlyprintk wouldn't
> print to a raw framebuffer. Otherwise:
Well, that could be hacked in, but I doubt that it can be
upstreamable. So it's serial-only.
> # ./devmem2 0xd8120000 w
> /dev/mem opened.
> Memory mapped at address 0x40001000.
> Value at address 0xD8120000 (0x40001000): 0x34260103
>
> Which matches the value in head-vt8500.S
That's strange. Any specific symptoms? What kind of root fs are you
using, could it be just a panic due to inability to mount root? Does
it initialize any USB devices?
Best,
Alexey
Paul Sokolovsky
On Mon, 23 May 2011 12:30:57 +0400
Alexey Charkov <alc...@gmail.com> wrote:
[]
> That's strange. Any specific symptoms? What kind of root fs are you
> using, could it be just a panic due to inability to mount root? Does
> it initialize any USB devices?
Ah, yes, sorry - it's common random-dot pattern on the LCD after
jumping to kernel. Specifically: I have few u-boot messages on the black
screen, then after bootm command, 90% of screen pixels are still black,
the rest are random color, and pattern also random, spanning entire
screen. All that is of course different from normal boot, when fbcon is
initialized, boot messages scroll, and specific error is visible on the
screen.
That can be lot of things of course (for example, different LCD init
for my LCD). What would be helpful is to know if master branch (after
wm8650 merge) was booted on any wm8505 device successfully.
>
> Best,
Alexey Charkov
> Hello,
>
> On Mon, 23 May 2011 12:30:57 +0400
> Alexey Charkov <alc...@gmail.com> wrote:
>
> []
>> That's strange. Any specific symptoms? What kind of root fs are you
>> using, could it be just a panic due to inability to mount root? Does
>> it initialize any USB devices?
>
> Ah, yes, sorry - it's common random-dot pattern on the LCD after
> jumping to kernel. Specifically: I have few u-boot messages on the black
> screen, then after bootm command, 90% of screen pixels are still black,
> the rest are random color, and pattern also random, spanning entire
> screen. All that is of course different from normal boot, when fbcon is
> initialized, boot messages scroll, and specific error is visible on the
> screen.
I still suspect that it may well be a root fs problem. A kernel panic
could look like this.
Basically, the fact that your display changes in _any_ way implies
that the kernel actually starts to execute and probably even reaches
wm8505fb initialization. Then it panics and draws funny random-art
pictures.
You could try to fill the preallocated framebuffer memory region with
0xff at board initialization as a check (should turn your random-art
beauty into a solid white fill).
> That can be lot of things of course (for example, different LCD init
> for my LCD). What would be helpful is to know if master branch (after
> wm8650 merge) was booted on any wm8505 device successfully.
They should be completely orthogonal, wm8650 stuff does not touch
wm8505 stuff (especially if you disable it in config). And Ed reported
successful boot on his wm8505 hardware after the GPIO mux-related
commit (which is after wm8650 addition).
Best,
Alexey
Alexey Charkov
Ah, yes: if your dots move around as the kernel boots, then it may be
due to a wrong panel selection. As there is no autodetection mechanism
available, one should either select a single panel resolution at
compile-time or issue an override in kernel command line (see the
respective Kconfig help).
Best,
Alexey
Ed Spiridonov
> Well, I don't have a serial cable,
Serial cable can be very useful (and not too difficult to make).
Paul Sokolovsky
Serial cable - yeah, and I have bunch of them from PocketPC times, but
where to attach it? I'm not going to disassemble this flaky device ;-).
Ed Spiridonov
> Yes, I have such attachment adapter, and I would think that external
> connecter should include serial port, but vendors are so strange
> nowadays... So, I'll try to poke inside and google for it, but I
> already googled a lot and never saw about serial via attachment
> adapter, so if you have any link handy, I'd appreciate it.
You can open this adapter and find four points, three are labeled as
RXD, TXD, GND.
Be careful, the tracks on the board is easily damaged (as you can see
on one photo), I filled soldering points with epoxy (you can see it on
another photo).
Angus Gratton
> 2011/5/23 Paul Sokolovsky <pmi...@gmail.com>:
> > Yes, I have such attachment adapter, and I would think that external
> > connecter should include serial port, but vendors are so strange
> > nowadays... So, I'll try to poke inside and google for it, but I
> > already googled a lot and never saw about serial via attachment
> > adapter, so if you have any link handy, I'd appreciate it.
>
> You can open this adapter and find four points, three are labeled as
> RXD, TXD, GND.
Is the serial port in the adapter the same ttyS0 serial port that's on
the main board?
On my M001, there is a serial port on the edge connector but it seems to
be a different one of the WM8505's 4 serial ports. I haven't tested to
see which one it is.
Of course, I assume you can redirect the kernel boot console with
console=ttyS<N> on the boot line, but AFAIK you can't change the u-boot
console easily.
- Angus
Ed Spiridonov
> On Mon, 2011-05-23 at 20:11 +0400, Ed Spiridonov wrote:
>> 2011/5/23 Paul Sokolovsky <pmi...@gmail.com>:
>> > Yes, I have such attachment adapter, and I would think that external
>> > connecter should include serial port, but vendors are so strange
>> > nowadays... So, I'll try to poke inside and google for it, but I
>> > already googled a lot and never saw about serial via attachment
>> > adapter, so if you have any link handy, I'd appreciate it.
>>
>> You can open this adapter and find four points, three are labeled as
>> RXD, TXD, GND.
>
> Is the serial port in the adapter the same ttyS0 serial port that's on
> the main board?
IMHO yes.
> On my M001, there is a serial port on the edge connector but it seems to
> be a different one of the WM8505's 4 serial ports. I haven't tested to
> see which one it is.
>
> Of course, I assume you can redirect the kernel boot console with
> console=ttyS<N> on the boot line, but AFAIK you can't change the u-boot
> console easily.
This port work as ttyWMT0 with Alexey's kernel. And it work with uboot as well.
Alexey Charkov
> 2011/5/24 Angus Gratton <g...@projectgus.com>:
>> On my M001, there is a serial port on the edge connector but it seems to
>> be a different one of the WM8505's 4 serial ports. I haven't tested to
>> see which one it is.
>>
>> Of course, I assume you can redirect the kernel boot console with
>> console=ttyS<N> on the boot line, but AFAIK you can't change the u-boot
>> console easily.
>
> This port work as ttyWMT0 with Alexey's kernel. And it work with uboot as well.
... which implies that the port is UART0. That is the only one we
actually initialize in current board code, and the one u-boot uses,
and the one vendor's kernels use.
Best,
Alexey
Paul Sokolovsky
Thanks for nice guides, Ed. I asked some guy to solder connector for
me, and then after spending whole evening sticking wire cuts into pin
sockets and cracking open my old Siemens data cable (who'd know it's
for old 12V RS232 and doesn't bother to work with contemporary TTL
levels), I finally got a boot trace. Waiting for my epoxy to solidify
now ;-).
I put your pictures at
https://sourceforge.net/apps/trac/linux-h4000/wiki/WM8505Tablet , hope
that's ok.
Ed Spiridonov
> I put your pictures at
> https://sourceforge.net/apps/trac/linux-h4000/wiki/WM8505Tablet , hope
> that's ok.
Of course, that must be ok; but this URL don't work for me ;)
Carlos Balseiro
> on one photo)
buy replacement of this boards?
Carlos Balseiro
Anyone knows any alternatavie point to solder TXD? I break a track
even trying to be as carefull as possible ... Also , is there is a
direct correspondence between this four points and for pins of the 30
pin connector, I would rather make a new cable.
If none of the above are possible, anyone knows where to buy
replacements for this boards?
Paul Sokolovsky
On Sun, 29 May 2011 10:30:03 -0700 (PDT)
Carlos Balseiro <haml...@gmail.com> wrote:
> Seems my last message got lost, so I will ask again just in case:
>
> Anyone knows any alternatavie point to solder TXD? I break a track
> even trying to be as carefull as possible ... Also , is there is a
> direct correspondence between this four points and for pins of the 30
> pin connector, I would rather make a new cable.
Sure, the dongle appears to be completely passive (just routes signals
from small 30-pin connector to "big" Ethernet/USB ports). You could
easily track wiring from 30-pin connector to serial pads with a
magnifying glass. But pins of 30-pin connector are very thin and
crowded, it wouldn't be too easy to solder to them either.
>
> If none of the above are possible, anyone knows where to buy
> replacements for this boards?
--
Ed Spiridonov
> Seems my last message got lost, so I will ask again just in case:
>
> Anyone knows any alternatavie point to solder TXD? I break a track
> even trying to be as carefull as possible ... Also , is there is a
> direct correspondence between this four points and for pins of the 30
> pin connector, I would rather make a new cable.
I draw correspondence for my adapter.
But different tablets use different adapters (some use apple's 30-pin
connector, my use another connector).
I'm not sure - is pinout same for all wm8505-based tablets or not.
Carlos Balseiro
to make a cable directly, I don't want to break the usb/rj45 adaptor,
it is too weak and I need it. If I get something to work I will post
schematics.
On May 30, 2:43 pm, Ed Spiridonov <edo....@gmail.com> wrote:
> 2011/5/29 Carlos Balseiro <hamlet...@gmail.com>:
> 297KViewDownload
Paul Sokolovsky
On Mon, 23 May 2011 20:11:30 +0400
Ed Spiridonov <edo...@gmail.com> wrote:
> 2011/5/23 Paul Sokolovsky <pmi...@gmail.com>:
> > Yes, I have such attachment adapter, and I would think that external
> > connecter should include serial port, but vendors are so strange
> > nowadays... So, I'll try to poke inside and google for it, but I
> > already googled a lot and never saw about serial via attachment
> > adapter, so if you have any link handy, I'd appreciate it.
>
> You can open this adapter and find four points, three are labeled as
> RXD, TXD, GND.
As a follow up, I finally soldered reusable usb-serial cable to attach
to serial connector previously soldered to the dongle. Output from
device works well, but when I type something into fully booted linux, I
get input overruns:
[GOVRH] VGA DAC DISCONNECT
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing init memory: 144K
/bin/sh: can't access tty; job control turned off
# gttyS0: 1 input overrun(s)
�g�httyS0: 2 input overrun(s)
�j�k�j�ittyS0: 4 input overrun(s)
�i�y�t�fttyS0: 4 input overrun(s)
�httyS0: 1 input overrun(s)
�h�k�qttyS0: 3 input overrun(s)
�w�ettyS0: 2 input overrun(s)
�r�
The char I input goes back well, but is followed by the question mark,
and overrun message. The cable loopback goes well, and at the early
stages of boot (u-boot and boot scroll) chars typed echoed back w/o
extra artifacts. At the same time hitting Enter key at the "Hit
Enter key to stop autoboot" message doesn't really stop default u-boot
processing.
I tried 3 different cables, including one I used during the previous
session, which I connected just with wire cuts between its and dongle
connector. Results are the same, and I'm sure it wasn't like, because I
tried to log in one serial into booted android, and didn't see any
overruns. So, this reduces suspects to the dongle/tablet itself.
Any idea what could cause this? Could epoxy change capacitance and lead
to such effect? (That's one big difference with my initial
experiements and these). Could static to such damage?
Paul Sokolovsky
On Mon, 23 May 2011 13:31:13 +0400
Alexey Charkov <alc...@gmail.com> wrote:
> 2011/5/23 Paul Sokolovsky <pmi...@gmail.com>:
> > Hello,
> >
> > On Mon, 23 May 2011 12:30:57 +0400
> > Alexey Charkov <alc...@gmail.com> wrote:
> >
> > []
> >> That's strange. Any specific symptoms? What kind of root fs are you
> >> using, could it be just a panic due to inability to mount root?
> >> Does it initialize any USB devices?
> >
> > Ah, yes, sorry - it's common random-dot pattern on the LCD after
> > jumping to kernel. Specifically: I have few u-boot messages on the
> > black screen, then after bootm command, 90% of screen pixels are
> > still black, the rest are random color, and pattern also random,
> > spanning entire screen. All that is of course different from normal
> > boot, when fbcon is initialized, boot messages scroll, and specific
> > error is visible on the screen.
>
> I still suspect that it may well be a root fs problem. A kernel panic
> could look like this.
>
> Basically, the fact that your display changes in _any_ way implies
> that the kernel actually starts to execute and probably even reaches
> wm8505fb initialization. Then it panics and draws funny random-art
>
Well, not necessarily, on PXA, weird changes on the display were
usually caused by wrong DRAM/display controller settings, so one can
visual how DRAM goes havoc due to wrong refresh ;-).
So well, with serial cable, I see u-boot transfer control to kernel,
and that's where it ends. Last stuff I see is:
"Booting kernel ..."
** exec: "sleep 1"
** exec: "bootm 0"
## Booting image at 00000000 ...
Image Name: Linux-2.6.39-rc3-gf784efb
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1559928 Bytes = 1.5 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
OK
No initrd
## Transferring control to Linux (at address 00008000) ...
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Here're 2 points: I'm loading uImage at address 0 - that works OK for
vendor kernel, and AFAIK, kernel is fully relocatable. And, there're
way to few dots after "Uncompressing Linux", for real kernel which
boots there're much more.
I guess, next step to deal with such situation would be to provide
knowing working complete defconfig. 900-bytes wmt_defconfig as provided
now doesn't do - it specifies 1% of kernel options, and rest 99% will
be set pretty randomly by Kconfig, causing unpredictable problems.
>
> You could try to fill the preallocated framebuffer memory region with
> 0xff at board initialization as a check (should turn your random-art
> beauty into a solid white fill).
>
> > That can be lot of things of course (for example, different LCD init
> > for my LCD). What would be helpful is to know if master branch
> > (after wm8650 merge) was booted on any wm8505 device successfully.
>
> They should be completely orthogonal, wm8650 stuff does not touch
> wm8505 stuff (especially if you disable it in config). And Ed reported
> successful boot on his wm8505 hardware after the GPIO mux-related
> commit (which is after wm8650 addition).
>
> Best,
> Alexey
--
Paul Sokolovsky
On Sun, 5 Jun 2011 13:57:13 +0300
Paul Sokolovsky <pmi...@gmail.com> wrote:
[]
> Uncompressing Linux... done, booting the kernel.
>
> Here're 2 points: I'm loading uImage at address 0 - that works OK for
> vendor kernel, and AFAIK, kernel is fully relocatable. And, there're
> way to few dots after "Uncompressing Linux", for real kernel which
> boots there're much more.
Ah, I see, since other kernel image compression algos were added in
recent kernels, it seems that uncompress routine no longer outputs a
dot for each block processed, what a shame.
Alexey Charkov
2011/6/5 Paul Sokolovsky <pmi...@gmail.com>:
I believe that it's not the case with our devices, as the bootloader
initializes graphics into a known-working state to display a logo.
> So well, with serial cable, I see u-boot transfer control to kernel,
> and that's where it ends. Last stuff I see is:
>
> "Booting kernel ..."
> ** exec: "sleep 1"
> ** exec: "bootm 0"
> ## Booting image at 00000000 ...
> Image Name: Linux-2.6.39-rc3-gf784efb
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 1559928 Bytes = 1.5 MB
> Load Address: 00008000
> Entry Point: 00008000
> Verifying Checksum ... OK
> OK
> No initrd
> ## Transferring control to Linux (at address 00008000) ...
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
>
> Here're 2 points: I'm loading uImage at address 0 - that works OK for
> vendor kernel, and AFAIK, kernel is fully relocatable. And, there're
> way to few dots after "Uncompressing Linux", for real kernel which
> boots there're much more.
This is perfectly fine, and it shows that the serial controller works
at least in the dumbest mode (register-based polled transmit-only).
This should suffice for early printk messages - please try to enable
those (via respective Kconfig option under Kernel debug, accompanied
by an 'earlyprintk' cmdline option).
> I guess, next step to deal with such situation would be to provide
> knowing working complete defconfig. 900-bytes wmt_defconfig as provided
> now doesn't do - it specifies 1% of kernel options, and rest 99% will
> be set pretty randomly by Kconfig, causing unpredictable problems.
This is intentionally created by hand with only the required
WMT-related options. The rest is set by Kconfig to respective default
values, rather than randomly. There are at least two reasons for this:
1. Looking at Linus' recent reactions to defconfig updates, there is
no way how he would ever merge a full .config saved as a defconfig, as
it will require updates with any Kconfig changes.
2. It will let us catch bugs that only reveal when reconfiguring the
kernel from default options, as it was the case when sparse IRQs were
introduced by default (but were disabled in my older config, where
default was different).
Best,
Alexey
Paul Sokolovsky
I probably miss a lot with changes in the recent kernel versions. Does
it mean that kernel is no longer going to print anything during boot, as
it did for ages, unless obscure for most people config options are
enabled and special boot arg is passed?
Anyway, thanks for continued hints, kernel starts up fine, and hangs at
[ 0.280000] Enabled support for WMT GE raster acceleration
I'll be looking into that.
>
> > I guess, next step to deal with such situation would be to provide
> > knowing working complete defconfig. 900-bytes wmt_defconfig as
> > provided now doesn't do - it specifies 1% of kernel options, and
> > rest 99% will be set pretty randomly by Kconfig, causing
> > unpredictable problems.
>
> This is intentionally created by hand with only the required
> WMT-related options. The rest is set by Kconfig to respective default
> values, rather than randomly. There are at least two reasons for this:
Well, those defaults are based on production x86 systems or something
of which Linus cares, and are essentially random in other lands, like
where barely documented, sparse-community ARM devices are hacked.
Example is DEBUG_LL - it's randomly not enabled by kernel for
aforementioned devices.
> 1. Looking at Linus' recent reactions to defconfig updates, there is
> no way how he would ever merge a full .config saved as a defconfig, as
> it will require updates with any Kconfig changes.
Well, defconfig for testing/QA is not necessarily the same as for
upstreaming.
> 2. It will let us catch bugs that only reveal when reconfiguring the
> kernel from default options, as it was the case when sparse IRQs were
> introduced by default (but were disabled in my older config, where
> default was different).
That's just another example that big guys' kernel defaults are random
and change randomly ;-).
Alexey Charkov
2011/6/5 Paul Sokolovsky <pmi...@gmail.com>:
<snip>
No, it only affects early debug. Your boot messages are lost because
the kernel stalls before it activates the proper serial driver with
its console support. Early printk, on the other hand, just pushes raw
characters to a specified register and busy-polls another register for
a "Ready" status.
> Anyway, thanks for continued hints, kernel starts up fine, and hangs at
>
> [ 0.280000] Enabled support for WMT GE raster acceleration
>
> I'll be looking into that.
I had this problem when I did not compile any filesystems, so it did
not even try to load any further. Did you confirm that your root fs
related stuff is in place? By that I mean the respective storage
driver, filesystem support built-in and 'root=/dev/foo' boot
parameter, most likely accompanied by a 'rootwait' (for USB and SD
storage options).
>> > I guess, next step to deal with such situation would be to provide
>> > knowing working complete defconfig. 900-bytes wmt_defconfig as
>> > provided now doesn't do - it specifies 1% of kernel options, and
>> > rest 99% will be set pretty randomly by Kconfig, causing
>> > unpredictable problems.
>>
>> This is intentionally created by hand with only the required
>> WMT-related options. The rest is set by Kconfig to respective default
>> values, rather than randomly. There are at least two reasons for this:
>
> Well, those defaults are based on production x86 systems or something
> of which Linus cares, and are essentially random in other lands, like
> where barely documented, sparse-community ARM devices are hacked.
> Example is DEBUG_LL - it's randomly not enabled by kernel for
> aforementioned devices.
DEBUG_LL has a boot performance overhead (busy-waits) and gives zero
benefit to people who are not willing to solder console connections or
who have no clue about what all those messages mean.
>> 1. Looking at Linus' recent reactions to defconfig updates, there is
>> no way how he would ever merge a full .config saved as a defconfig, as
>> it will require updates with any Kconfig changes.
>
> Well, defconfig for testing/QA is not necessarily the same as for
> upstreaming.
I'd rather distinguish between "my config that works for me right now
and that you could probably try as well" and "default minimal config
that is expected to work, please report if it does not" ;-)
>> 2. It will let us catch bugs that only reveal when reconfiguring the
>> kernel from default options, as it was the case when sparse IRQs were
>> introduced by default (but were disabled in my older config, where
>> default was different).
>
> That's just another example that big guys' kernel defaults are random
> and change randomly ;-).
It was not so random, it reflected quite a major change in the kernel
itself that we missed by not yet being upstream and relying on a
previous config that just side-stepped a real issue with the code.
Best,
Alexey
Paul Sokolovsky
Yep, I googled, and it's in kernel for years, but I didn't use it
before, somehow handhelds.org kernels seemed to have dumped all stuff
to serial without it, maybe we had special patches for that.
>
> > Anyway, thanks for continued hints, kernel starts up fine, and
> > hangs at
> >
> > [ 0.280000] Enabled support for WMT GE raster acceleration
> >
> > I'll be looking into that.
>
> I had this problem when I did not compile any filesystems, so it did
> not even try to load any further. Did you confirm that your root fs
> related stuff is in place? By that I mean the respective storage
> driver, filesystem support built-in and 'root=/dev/foo' boot
> parameter, most likely accompanied by a 'rootwait' (for USB and SD
> storage options).
No, it's not that simple. So, after spending entire evening+ on it
and (early_)printk-tracing thru layers and layers of kernel, I reduced
lock up place to drivers/video/sysimgblt.c at:
+//early_printk(KERN_INFO "+%s: here3.3: %x\n", __FUNCTION__, dst);
*dst++ = (end_mask & eorx) ^ bgx;
+//early_printk(KERN_INFO "+%s: here3.4\n", __FUNCTION__);
So, it just hanged in writing to memory, and dst value was kinda of
0xceXXXXXX. Then I had a look how fbmem is allocated in your kernel,
and saw it's kinda done from normal memory, whereas vendor kernel seem
to reserve range of physical memory and boots with mem=237M. I actually
was having it in my kernel command line all the time. Once I removed
that, lock up was gone it finally booted up to rootfs access. But
without mem= kernel recognized only 128Mb memory, and with mem=256M it
locks up again.
Well, I'm not sure what happens there. My guess is that it trashes
kernel code/stack or something. I guess, there's less chance it trashes
SOC MMIO, but also possible.
> >> > I guess, next step to deal with such situation would be to
> >> > provide knowing working complete defconfig. 900-bytes
> >> > wmt_defconfig as provided now doesn't do - it specifies 1% of
> >> > kernel options, and rest 99% will be set pretty randomly by
> >> > Kconfig, causing unpredictable problems.
> >>
> >> This is intentionally created by hand with only the required
> >> WMT-related options. The rest is set by Kconfig to respective
> >> default values, rather than randomly. There are at least two
> >> reasons for this:
> >
> > Well, those defaults are based on production x86 systems or
> > something of which Linus cares, and are essentially random in other
> > lands, like where barely documented, sparse-community ARM devices
> > are hacked. Example is DEBUG_LL - it's randomly not enabled by
> > kernel for aforementioned devices.
>
> DEBUG_LL has a boot performance overhead (busy-waits) and gives zero
> benefit to people who are not willing to solder console connections or
> who have no clue about what all those messages mean.
I don't share such attitude towards the users ;-). Choosing between
performance overhead during initial boot stages and complete inability
to diagnose a problem, I prefer the first. And users who're not willing
to solder/don't have a clue today, will want to do that tomorrow, and
configuring thousands of options in kernel and deploy new kernel is a
bit harder than solder few wires. So, it rather should be the other way
around: there should be adequate diagnostics by default, and people
smart enough to count CPU cycles, can "optimize" that for themselves.
> >> 1. Looking at Linus' recent reactions to defconfig updates, there
> >> is no way how he would ever merge a full .config saved as a
> >> defconfig, as it will require updates with any Kconfig changes.
> >
> > Well, defconfig for testing/QA is not necessarily the same as for
> > upstreaming.
>
> I'd rather distinguish between "my config that works for me right now
> and that you could probably try as well" and "default minimal config
> that is expected to work, please report if it does not" ;-)
I've been advocating for elaborated defconfig, standard for a project
(ideally, across projects) which sets baseline for hardware support and
defined set of hardware-independent features, which can be used for
sustainable testing and debugging. Like, all people agree (with help
of maintainer) to do testing (and usage if applicable) using that
defconfig, then different results can be compared, issues reproduced,
etc. Doing in that way is "engineering", not doing that is something
completely different ;-).
That's of course what "big" distros do, even Gentoo - you don't need to
enable common filesystems before being able to boot kernel at all.
>
> >> 2. It will let us catch bugs that only reveal when reconfiguring
> >> the kernel from default options, as it was the case when sparse
> >> IRQs were introduced by default (but were disabled in my older
> >> config, where default was different).
> >
> > That's just another example that big guys' kernel defaults are
> > random and change randomly ;-).
>
> It was not so random, it reflected quite a major change in the kernel
> itself that we missed by not yet being upstream and relying on a
> previous config that just side-stepped a real issue with the code.
Sure, I understand that all upstream changes are important and mostly
good. The talk is about development focus and aims - they're different
for upstream kernel and device porting project. It's not universally
useful to immediately follow upstream twists, if there're more
important things for specific port - like flash, mmc, sound, pm, and
integrating that stuff together.