Re: community Digest, Vol 269, Issue 10
On Sunday 15 January 2012 19:07:12 Rashid wrote: > Using Qt moko 25 or 28. You should download qtmoko v35 from this page: http://sourceforge.net/projects/qtmoko/files/ and use the instructions there to flash it. > My freerunner wont book. HDQ error: 1 > Any Ideas? More description please. Booting from SD card or NAND? Which bootloader are you using? You will need qi-v35. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ubifs/NAND problem?
For the record, I've never had ubifs work by flashing an image using dfu-util. I did get it to work using nandwrite though! Basically boot into your working uSD install and put your ubifs image on there. Then use nandwrite to flash it into nand (it's also much faster than dfu-util). See http://wiki.openmoko.org/wiki/Ubifs ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ubifs/NAND problem?
On Sunday 15 January 2012 23:29:58 Boudewijn wrote: > On Sunday 15 January 2012 22:53:24 Boudewijn wrote: > > On Sunday 15 January 2012 21:56:04 Ivan Matveev wrote: > > > On Sun, 15 Jan 2012 18:10:11 +0100 > > > > > > Boudewijn wrote: > > > > The Freerunner still won't boot from NAND though. I reflashed with > > > > SHR-core (and SHR's ubi-qi), to no avail. After that I flashed QtMoko > > > > v35 (and QtMoko's qi v35). > > > > > > Hi Boudewijn, > > > I had a similar problem, couldn't boot anything from NAND(qi or uboot > > > the same). Jffs worked fine. > > > While trying different UBIFS distributions I have accidently flashed > > > kernel to where bootloader should be. Reflashed everything as it should > > > be, and the phone started to boot from NAND. > > > > Thanks for the suggestion! I actually started writing as a follow-up to > > your thread, but since you started out with v36 and ended with v35 I > > started a new one (I started with v35 a couple of times right away) > > > TL;DR: > I overwrote my boot partition and kernel partition with useless (in this > context) data multiple times. I expected Qi to break at some point, but it > didn't. It also did not become "unbroken": it refuses to boot the kernel in > NAND. > > Any pointer? > > > Boudewijn > > PS: For now I'll start reading about u-boot on the wiki. First achievement after downloading gena2x' u-boot to the FR: Qi is gone. After that, I downloaded Qi again, resulting in a booting SHR from uSD. For now I'll focus my attention on the kernel partition; the boot loader seems OK. I downloaded one of the last SHR-kernels (2.6.39-xx16...), to see if anything happened. That's not the case: upon booting I still get SHR from uSD, not QtMoko with a SHR kernel and a crash after half a minute. Lacking a crash, a boot log or anything except a running SHR, I turned back to u-boot, and continued following gena2x' excellent howto. Lacking a running environment to copy the Qi-settings from, I started off with his sample config. Now I got somewhere: using the "boot jffs from NAND" option crashed the UBI- kernel (once again, I realize there's UBI to be had here anyway ;-) ) Just before the crash (unable to mount root fs on unknown-block(0,0) ), it listed the list of all partitions, with addresses (and driver? behind every item). With some luck, those are all jffs-driver on UBI-fs errors. Choosing the NAND/ubi-zlib boot option, there were some warnings, I guess relating to running SHRs kernel on QtMoko. Anyway, QtMoko booted! Gennady, thank you! :-) Boudewijn smime.p7s Description: S/MIME cryptographic signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ubifs/NAND problem?
On Sunday 15 January 2012 22:53:24 Boudewijn wrote:
> On Sunday 15 January 2012 21:56:04 Ivan Matveev wrote:
> > On Sun, 15 Jan 2012 18:10:11 +0100
> >
> > Boudewijn wrote:
> > > Hi List,
> > >
> > > I have problems with NAND, it seems, but I don't know how to
> > > troubleshoot it.
> > >
> > > For a while I have been unable to boot SHR from NAND, but since I had
> > > another install on uSD, it didn't really matter. Lately I wanted to
> > > move to NAND anyway, to free up the relatively fast uSD for my
> > > Phoenux.
> > >
> > > The Freerunner still won't boot from NAND though. I reflashed with
> > > SHR-core (and SHR's ubi-qi), to no avail. After that I flashed QtMoko
> > > v35 (and QtMoko's qi v35). No better result either. (For a moment I
> > > thought the MD5 sum was incorrect, downloaded again and flashed, but
> > > it turned out Sourceforge hid part of the sum when there's no
> > > mouseover).
> >
> > Hi Boudewijn,
> > I had a similar problem, couldn't boot anything from NAND(qi or uboot
> > the same). Jffs worked fine.
> > While trying different UBIFS distributions I have accidently flashed
> > kernel to where bootloader should be. Reflashed everything as it should
> > be, and the phone started to boot from NAND.
> > The distrib was QtMoko v35.
> > I think there could be some wrong data or bad blocks somewhere that
> > were erased by flashing kernel to the wrong place. Or some bug was fixed
> > in qi or kernel. Cant check.
>
> Thanks for the suggestion! I actually started writing as a follow-up to
> your thread, but since you started out with v36 and ended with v35 I
> started a new one (I started with v35 a couple of times right away)
>
> If I understand correctly, you now use UBI, not jffs, don't you?
>
> If all goes well, I can send "success" in a couple of minutes :-)
What I did:
- flash kernel partition with random 27-meg PDF
- flash boot partition with kernel image
- "boot" in u-boot (NOR)
--> wrong image, returning to u-boot-menu
- "reboot" in u-boot (NOR)
--> booting SHR from uSD using Qi
--> Qi is not broken? I have not patched my u-boot (NOR) in any way to cope
with large kernels or other filesystems.
I used neotool for flashing. It seems it did not flash the kernel partition:
bytes_per_hash=539430
Copying data from PC to DFU device
Starting download: [Resetting USB to switch back to runtime mode
(there are no hashes showing the download, so maybe nothing is downloaded)
Some data got downloaded to the boot partition, but fewer hashes (of more
bytes) than usual:
bytes_per_hash=44949
Copying data from PC to DFU device
Starting download: [#Resetting USB to switch back to runtime mode
On second try, I used a PDF of 3 MB for the kernel partition, and a <1 MB PDF
for boot.
This time the "kernel" downloaded as supposed, and the "boot loader" has "more
hashes", but Qi runs anyway.
Third time I skipped the kernel partition, and downloaded a 40k-log as boot
loader. That gave a long enough hash-line ("smaller hashes", of course). Funny
enough, this time DFU-util exited with an error (Thanks Thormod/Stephan!):
bytes_per_hash=806
Copying data from PC to DFU device
Starting download: [##]
finished!
state(10) = dfuERROR, status(1) = File is not targeted for use by this
device
Finally I downloaded the QtMoko-files (kernel v35 and qi v35), removed USB and
battery, reconnected power supplies and sat back. SHR. No offense, SHR is nice
enough ;-) But not what I had in mind for tonight.
I did notice something I was looking for earlier on the u-boot screen. The
DFU-util log says:
Starting Atomic DFU DOWNLOAD to partition 'u-boot'
device 0 offset 0x4, size 0x4
(BBT address? Too slow typing to catch it before FR shut down)...
At least I got some offset for dev 0 now, but I come to realize that it's not
UBI at all, so no gain here.
Sorry for the long story.
TL;DR:
I overwrote my boot partition and kernel partition with useless (in this
context) data multiple times. I expected Qi to break at some point, but it
didn't. It also did not become "unbroken": it refuses to boot the kernel in
NAND.
Any pointer?
Boudewijn
PS: For now I'll start reading about u-boot on the wiki.
smime.p7s
Description: S/MIME cryptographic signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: ubifs/NAND problem?
On Sunday 15 January 2012 21:56:04 Ivan Matveev wrote: > On Sun, 15 Jan 2012 18:10:11 +0100 > > Boudewijn wrote: > > Hi List, > > > > I have problems with NAND, it seems, but I don't know how to > > troubleshoot it. > > > > For a while I have been unable to boot SHR from NAND, but since I had > > another install on uSD, it didn't really matter. Lately I wanted to > > move to NAND anyway, to free up the relatively fast uSD for my > > Phoenux. > > > > The Freerunner still won't boot from NAND though. I reflashed with > > SHR-core (and SHR's ubi-qi), to no avail. After that I flashed QtMoko > > v35 (and QtMoko's qi v35). No better result either. (For a moment I > > thought the MD5 sum was incorrect, downloaded again and flashed, but > > it turned out Sourceforge hid part of the sum when there's no > > mouseover). > > Hi Boudewijn, > I had a similar problem, couldn't boot anything from NAND(qi or uboot > the same). Jffs worked fine. > While trying different UBIFS distributions I have accidently flashed > kernel to where bootloader should be. Reflashed everything as it should > be, and the phone started to boot from NAND. > The distrib was QtMoko v35. > I think there could be some wrong data or bad blocks somewhere that > were erased by flashing kernel to the wrong place. Or some bug was fixed > in qi or kernel. Cant check. Thanks for the suggestion! I actually started writing as a follow-up to your thread, but since you started out with v36 and ended with v35 I started a new one (I started with v35 a couple of times right away) If I understand correctly, you now use UBI, not jffs, don't you? If all goes well, I can send "success" in a couple of minutes :-) Boudewijn smime.p7s Description: S/MIME cryptographic signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ubifs/NAND problem?
On Sunday 15 January 2012 18:58:29 Rico Rommel wrote: > Am Sonntag, 15. Januar 2012, 18:10:11 schrieb Boudewijn: > > [ 1274.33] UBI: attaching mtd6 to ubi0 > > [ 1274.33] UBI: physical eraseblock size: 131072 bytes (128 KiB) > > [ 1274.33] UBI: logical eraseblock size:129024 bytes > > [ 1274.33] UBI: smallest flash I/O unit:2048 > > [ 1274.33] UBI: sub-page size: 512 > > [ 1274.33] UBI: VID header offset: 512 (aligned 512) > > [ 1274.33] UBI: data offset:2048 > > [ 1274.33] UBI error: validate_ec_hdr: bad VID header offset 2048, > > expected 512 > > [ 1274.33] UBI error: validate_ec_hdr: bad EC header > > [ 1274.33] UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0 > > [ 1274.33] Unable to handle kernel paging request at virtual address > > 00100104 > > > > What does it try tell me? What can I do about it? > > I have to specify the data offset manually. > > Try passing the options > > ubi.mtd=6,2048 root=ubi0:name_of_rootfs or > ubi.mtd=6,2048 root=ubi0_0 > > to kernel or use > > ubiattach -m 6 -O 2048 > > at commandline. > > Rico Thanks, that works. I used the commandline, which gave me /dev/ubi0_0 (and equally /dev/ubi0), besides /dev/ubi_ctrl. After that I can mount -t ubifs /dev/ubi0_0 /mnt/ and it nicely shows my QtMoko v35 installation. I tried the same with partitions 0-5, but no luck there (either with/without - O 2048; perhaps they need another offset). The fact that no distro will boot gives reason to think that the kernel partition has a problem. I consulted the wiki to find out which offset might be applicable, and found the bad blocks [1] page. I could find out which blocks are not good using u-boot: "The u-boot command "nand bad" lists the offsets of the bad blocks." I'm not experienced in either serial interfacing nor calculating between memory mappings and partition tables. I have an idea what to do, but not clear enough to start right away. If other things fail, I'll give it a try anyway :-) I'll first give Ivans method of flashing a way to big file to a partition a try, it might shake up things enough to start writing to a good location afterward. (I guess it will just start complaining about lack of space, instead of breaking more than I intended...) Boudewijn [1] http://wiki.openmoko.org/wiki/NAND_bad_blocks smime.p7s Description: S/MIME cryptographic signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ubifs/NAND problem?
On Sun, 15 Jan 2012 18:10:11 +0100 Boudewijn wrote: > Hi List, > > I have problems with NAND, it seems, but I don't know how to > troubleshoot it. > > For a while I have been unable to boot SHR from NAND, but since I had > another install on uSD, it didn't really matter. Lately I wanted to > move to NAND anyway, to free up the relatively fast uSD for my > Phoenux. > > The Freerunner still won't boot from NAND though. I reflashed with > SHR-core (and SHR's ubi-qi), to no avail. After that I flashed QtMoko > v35 (and QtMoko's qi v35). No better result either. (For a moment I > thought the MD5 sum was incorrect, downloaded again and flashed, but > it turned out Sourceforge hid part of the sum when there's no > mouseover). Hi Boudewijn, I had a similar problem, couldn't boot anything from NAND(qi or uboot the same). Jffs worked fine. While trying different UBIFS distributions I have accidently flashed kernel to where bootloader should be. Reflashed everything as it should be, and the phone started to boot from NAND. The distrib was QtMoko v35. I think there could be some wrong data or bad blocks somewhere that were erased by flashing kernel to the wrong place. Or some bug was fixed in qi or kernel. Cant check. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community Digest, Vol 269, Issue 10
Using Qt moko 25 or 28. My freerunner wont book. HDQ error: 1 Any Ideas? Greets Rash ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ubifs/NAND problem?
Am Sonntag, 15. Januar 2012, 18:10:11 schrieb Boudewijn: > [ 1274.33] UBI: attaching mtd6 to ubi0 > [ 1274.33] UBI: physical eraseblock size: 131072 bytes (128 KiB) > [ 1274.33] UBI: logical eraseblock size:129024 bytes > [ 1274.33] UBI: smallest flash I/O unit:2048 > [ 1274.33] UBI: sub-page size: 512 > [ 1274.33] UBI: VID header offset: 512 (aligned 512) > [ 1274.33] UBI: data offset:2048 > [ 1274.33] UBI error: validate_ec_hdr: bad VID header offset 2048, > expected 512 > [ 1274.33] UBI error: validate_ec_hdr: bad EC header > [ 1274.33] UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0 > [ 1274.33] Unable to handle kernel paging request at virtual address > 00100104 > > What does it try tell me? What can I do about it? I have to specify the data offset manually. Try passing the options ubi.mtd=6,2048 root=ubi0:name_of_rootfs or ubi.mtd=6,2048 root=ubi0_0 to kernel or use ubiattach -m 6 -O 2048 at commandline. Rico signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ubifs/NAND problem?
On Sunday 15 January 2012 18:10:11 Boudewijn wrote: > Hi List, > > I have problems with NAND, it seems, but I don't know how to troubleshoot > it. > > For a while I have been unable to boot SHR from NAND, but since I had > another install on uSD, it didn't really matter. Lately I wanted to move > to NAND anyway, to free up the relatively fast uSD for my Phoenux. > > The Freerunner still won't boot from NAND though. I reflashed with SHR-core > (and SHR's ubi-qi), to no avail. After that I flashed QtMoko v35 (and > QtMoko's qi v35). No better result either. (For a moment I thought the MD5 > sum was incorrect, downloaded again and flashed, but it turned out > Sourceforge hid part of the sum when there's no mouseover). > > I used to be able to mount jffs2-partitions, but mounting ubifs seems a bit > different (or broken otherwise in my installation) > > I have tried: > - using the mtdblock6-device > - using the ubi-device (not available) [1] > - using the device-less method [1] > - using ubiattach (might create a dev node, but segfaults on mtd6 and hangs > on mtd6ro > > I guess ubifs is in the kernel; there's no such thing as ubi in lsmod, and > modprobe ubifs returns an error. I added the modules from SHR-core, but > they do not include UBI. > > dmesg gives some info, see attached text for a bit more: > > [ 1274.33] UBI: attaching mtd6 to ubi0 > [ 1274.33] UBI: physical eraseblock size: 131072 bytes (128 KiB) > [ 1274.33] UBI: logical eraseblock size:129024 bytes > [ 1274.33] UBI: smallest flash I/O unit:2048 > [ 1274.33] UBI: sub-page size: 512 > [ 1274.33] UBI: VID header offset: 512 (aligned 512) > [ 1274.33] UBI: data offset:2048 > [ 1274.33] UBI error: validate_ec_hdr: bad VID header offset 2048, > expected 512 > [ 1274.33] UBI error: validate_ec_hdr: bad EC header > [ 1274.33] UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0 > [ 1274.33] Unable to handle kernel paging request at virtual address > 00100104 > > What does it try tell me? What can I do about it? > > Boudewijn By the way, I noticed the partitions start at 0, so partition 6 is 7, so I repeated with 5 instead. It does not segfault, it just hangs (ctrl-c gives no response other than printingg ^C, ctrl-d does not quit the session). No new mention of "attach" or "ubi" in dmesg either. Boudewijn smime.p7s Description: S/MIME cryptographic signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
ubifs/NAND problem?
Hi List, I have problems with NAND, it seems, but I don't know how to troubleshoot it. For a while I have been unable to boot SHR from NAND, but since I had another install on uSD, it didn't really matter. Lately I wanted to move to NAND anyway, to free up the relatively fast uSD for my Phoenux. The Freerunner still won't boot from NAND though. I reflashed with SHR-core (and SHR's ubi-qi), to no avail. After that I flashed QtMoko v35 (and QtMoko's qi v35). No better result either. (For a moment I thought the MD5 sum was incorrect, downloaded again and flashed, but it turned out Sourceforge hid part of the sum when there's no mouseover). I used to be able to mount jffs2-partitions, but mounting ubifs seems a bit different (or broken otherwise in my installation) I have tried: - using the mtdblock6-device - using the ubi-device (not available) [1] - using the device-less method [1] - using ubiattach (might create a dev node, but segfaults on mtd6 and hangs on mtd6ro I guess ubifs is in the kernel; there's no such thing as ubi in lsmod, and modprobe ubifs returns an error. I added the modules from SHR-core, but they do not include UBI. dmesg gives some info, see attached text for a bit more: [ 1274.33] UBI: attaching mtd6 to ubi0 [ 1274.33] UBI: physical eraseblock size: 131072 bytes (128 KiB) [ 1274.33] UBI: logical eraseblock size:129024 bytes [ 1274.33] UBI: smallest flash I/O unit:2048 [ 1274.33] UBI: sub-page size: 512 [ 1274.33] UBI: VID header offset: 512 (aligned 512) [ 1274.33] UBI: data offset:2048 [ 1274.33] UBI error: validate_ec_hdr: bad VID header offset 2048, expected 512 [ 1274.33] UBI error: validate_ec_hdr: bad EC header [ 1274.33] UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0 [ 1274.33] Unable to handle kernel paging request at virtual address 00100104 What does it try tell me? What can I do about it? Boudewijn [ 1274.33] UBI: attaching mtd6 to ubi0 [ 1274.33] UBI: physical eraseblock size: 131072 bytes (128 KiB) [ 1274.33] UBI: logical eraseblock size:129024 bytes [ 1274.33] UBI: smallest flash I/O unit:2048 [ 1274.33] UBI: sub-page size: 512 [ 1274.33] UBI: VID header offset: 512 (aligned 512) [ 1274.33] UBI: data offset:2048 [ 1274.33] UBI error: validate_ec_hdr: bad VID header offset 2048, expected 512 [ 1274.33] UBI error: validate_ec_hdr: bad EC header [ 1274.33] UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0 [ 1274.33] Unable to handle kernel paging request at virtual address 00100104 [ 1274.33] pgd = c6ff [ 1274.33] [00100104] *pgd=36ed6831, *pte=, *ppte= [ 1274.33] Internal error: Oops: 817 [#1] [ 1274.33] last sysfs file: /sys/class/ubi/version [ 1274.33] Modules linked in: snd_soc_wm8753 snd_soc_s3c24xx snd_soc_neo1973_wm8753 snd_soc_s3c24xx_i2s snd_soc_dfbmcs320 snd_soc_core snd_pcm snd_timer snd soundcore snd_page_alloc rfcomm ppp_generic slhc ohci_hcd usbcore ipv6 hidp g_ether s3c2410_udc bnep bluetooth ar6000 [ 1274.33] CPU: 0Not tainted (2.6.39.4 #1) [ 1274.33] PC is at kmem_cache_destroy+0x40/0xfc [ 1274.33] LR is at kmem_cache_destroy+0x34/0xfc [ 1274.33] pc : []lr : []psr: 6013 [ 1274.33] sp : c6f77e30 ip : 0004 fp : 0200 [ 1274.33] r10: c6f2dcb4 r9 : c6f2dcb4 r8 : c03f2528 [ 1274.33] r7 : ffea r6 : c6f2dcac r5 : c6f2dca0 r4 : c78bf4e0 [ 1274.33] r3 : 00200200 r2 : 00100100 r1 : c78bf4e0 r0 : c78bf4e0 [ 1274.33] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 1274.33] Control: c000717f Table: 36ff DAC: 0015 [ 1274.33] Process ubiattach (pid: 787, stack limit = 0xc6f76270) [ 1274.33] Stack: (0xc6f77e30 to 0xc6f78000) [ 1274.33] 7e20: c6f2dca0 c01fc0c4 c6f2dca0 [ 1274.33] 7e40: c6f51800 ffea c03f2528 c01fc3e8 00d2 c01f40d0 [ 1274.33] 7e60: 00d0 c6f2dcac 37d3 c7973800 c6f2dcbc c6f51800 c6f2dca4 c0092a40 [ 1274.33] 7e80: 00d2 37d3 c7973800 c6f51800 c7973800 0800 [ 1274.33] 7ea0: 0200 c01f40e4 c6f77ec4 07ff 0068 c7810260 c7409834 bef07ae8 [ 1274.33] 7ec0: c7973800 40186f40 0003 c0026fe4 c6f76000 b858 c01f49b0 [ 1274.33] 7ee0: 0006 c797cb94 bef07ae8 [ 1274.33] 7f00: 40186f40 c00a9194 c6fe8005 c740bdd4 c797cb94 0101 0004 [ 1274.33] 7f20: c6e8a228 bf54 00014a3c c6f75560 [ 1274.33] 7f40: 0003 c6fe8000 c6e8a220 0003 c6e8a228 0020 [ 1274.33] 7f60: c6fe8000 c6e8a220 bef07ae8 40186f40 0003 c0026fe4 c6f76000 [ 1274.33] 7f80: b858 c00a96a0
Re: GTA04 Installation Service for Switzerland and other Non-EU countries
We are willing to undertake this service in India. Rakshat Ida Systems On 1/14/12, Dr. H. Nikolaus Schaller wrote: > We got several requests for the GTA04 installation service > > http://www.handheld-linux.com/wiki.php?page=GTA04%20Installation%20Service > > from countries not within the EU. This makes customs processing > a little complex, because the owner has to send his GTA02 to us with > proper declaration and notes so that we don't have to pay incoming taxes. > > Then, we do the installation and have to export a partial GTA02 plus a new > GTA04 board. > > This is not easily declared properly so that we do not risk that the device > gets stuck at customs. And, we have somehow to prove that the GTA02 is > the same as the one that was imported. > > So I would like to ask if there are people in these countries who would > want to handle the installation service locally. We would send a GTA04 > board to them, the GTA02 owner would send his GTA02 to them and > they would do the installation. And finally send the device back. > > If you are trustworthy, and willing to do such upgrades, please contact me. > > Nikolaus > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- -- Please use Firefox as your web browser. Its protects you from spyware and is also a very feature rich browser. www.firefox.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
