http://blog.gmane.org/gmane.os.netbsd.ports.arm hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3377 <pre>I'm thinking of ordering one of these for the heck of it: http://apc.io/about/ Does anyone know of a reason why this wouldn't be supported with NetBSD? It might be too early to know I guess. There are other machines out there that are interesting as well. The Raspberry Pi won't be available for a while so one of these other alternatives might be a better option. Andy </pre> Andy Ruhl 2012-05-25T15:42:21 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3376 <pre> Kate F wrote: For speed, after build.sh has created the tools for you it will create nbmake-evbarm, this is a wrapper around nbmake to set up the build environment, you should be able to run it in your kernel build directory - src/sys/arch/evbarm/compile/XYZ in your example. [snip] Yes. I don't think you have verified this, to make the netbsd.gz.ub file 'netbsd' has been gzipped before prepending a U-boot header that identifies it as a NetBSD kernel. I don't think this part is likely to go wrong though. The kernel doesn't get relocated as such, U-boot either copies or uncompresses it down to the load address specified in the U-boot header. The boot process then relies on using PC-relative addressing for everything until the code in marvell_start.S has set up a simple pagetable. In order for everything to work properly the final mapping defined in mmu_init_table needs to be correct, it is: VA 0xc0000000..0xc7ffffff to PA 0x00000000..0x07ffffff If the kernel gets copied to the wrong place by U-boot then stuff will also be at incorrect addresses when the MMU is turned on. The comment near the top of marvell_start.S is wrong, we started out building the kernel to run at 0x00200000 then gradually moved it down to 0x00008000. I would try to find out where the kernel has actually been put by U-boot. Robert Swindells </pre> Robert Swindells 2012-05-24T20:06:01 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3375 <pre> I'm cross-compiling from a Linux amd64 machine: ./build.sh -u -m evbarm kernel=XYZ Ok, so here's where I am currently. In the kernel image, my symbol has all-bytes-zero: iona% arm--netbsdelf-nm netbsd | sort | grep consinit_called c046e7bc d consinit_called.9907 iona% iona% arm--netbsdelf-objdump -j .data -s netbsd | grep -C 2 c046e7b. c046e790 f0c034c0 00000000 00000000 6c000000 ..4.........l... c046e7a0 02000000 e04915c0 0c4a15c0 908715c0 .....I...J...... c046e7b0 808715c0 00000000 00000000 00000000 ................ c046e7c0 00c20100 004b0000 00000000 00000000 .....K.......... c046e7d0 0000ffff 00000000 f86836c0 78000000 .........h6.x... iona% Unfortunately calling sprintf hangs. So I wrote something to print out hex values myself. Please excuse them being in reverse order. void KW_DUMP(void *q, size_t z) { size_t i; const unsigned char *p; p = q; for (i = 0; i &lt; z; i++) { const char *hex = "0123456789ABCDEF"; KW_DBG(hex[(p[i] &gt;&gt; 4) &amp; 0xf]); KW_DBG(hex[(p[i] &gt;&gt; 0) &amp; 0xf]); } } The value of that symbol as printed at runtime, and its address: { void *acic; KW_PUTS("consinit_called = "); KW_DUMP(&amp;consinit_called, sizeof consinit_called); KW_PUTS("\r\n"); acic = &amp;consinit_called; KW_PUTS("&amp;consinit_called = "); KW_DUMP(&amp;acic, sizeof acic); KW_PUTS("\r\n"); acic = (void *) (0x8000U + (unsigned) &amp;consinit_called - 0xc0000000U); KW_PUTS("phys. 2 &amp;consinit_called = "); KW_DUMP(&amp;acic, sizeof acic); KW_PUTS("\r\n"); KW_PUTS("phys. 2 consinit_called = "); KW_DUMP(acic, sizeof consinit_called); KW_PUTS("\r\n"); } Prints: consinit_called = FCE1EBCB &amp;consinit_called = BCE746C0 phys. 2 &amp;consinit_called = BC674700 phys. 2 consinit_called = 00000000 Fortunately this pattern (FCE1EBCB, or rather CBEBE1FC) is quite recognisable. I only found one occurance in the kernel image, so I assume that's the same pattern I'm seeing. It lives at c015588 relative to the start of the kernel. Now, I can see that from U-boot: Marvell&gt;&gt; md 0046e7bc 0046e7bc: cbebe1fc 3de0f3fb 7fc4e7af f5a473bf .......=.....s.. Which I zeroed out just to be sure I'm looking at the right thing: Marvell&gt;&gt; mw 0046e7bc 0 4 Marvell&gt;&gt; Marvell&gt;&gt; md 0046e7bc 0046e7bc: 00000000 00000000 00000000 00000000 ................ And lo and behold, booting prints out zeroes for my symbol's value: Marvell&gt;&gt; tftpboot 2000000 netbsd.gz.ub; bootm 2000000 ... consinit_called = 00000000 &amp;consinit_called = BCE746C0 So to recap: - the value in the kernel image is correct (all zeroes); - the value in the kernel image after tftpboot copies it (to 0x2000000 onwards) is correct; - the value after relocating to the load address 0x8000 is now somehow FCE1EBCB So, my current hypothesis is that during relocation, the address of this symbol is somehow being pointed at the wrong thing. I think the zeroed bytes are present - somewhere - but the symbol is looking at some other unrelated part of the image. It feels like an offset is wrong, somewhere. I don't know where. Does that sound reasonable? Next: - Try to find where the all-zeroed bytes actually are, after relocating - Find what the difference in offset is. I tried this last night, and I tentatively think this symbol is about 318F3C bytes off from where it ought to be. But that's not a nice round number, and so I am dubious of it. Am I on the right track? </pre> Kate F 2012-05-24T17:06:43 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3374 <pre> Kate K wrote: [snip] You can inspect netbsd using nm and objdump. % arm--netbsdelf-nm netbsd | sort &gt; lst1 % grep consinit_called lst1 c038ab7c d consinit_called.9374 Sorting the output will also let you see which variables are near to consinit_called in case it is being overwritten by something else. % arm--netbsdelf-objdump -j .data -s netbsd &gt; lst2 ... c038ab40 a00901c0 b40901c0 c80901c0 dc0901c0 ................ c038ab50 9ca127c0 00000000 00000000 6c000000 ..'.........l... c038ab60 02000000 28aa0ec0 54aa0ec0 28cd0ec0 ....(...T...(... c038ab70 18cd0ec0 00000000 00000000 00000000 ................ c038ab80 00c20100 004b0000 00000000 00000000 .....K.......... c038ab90 0000ffff 00000000 00000000 c4c10ec0 ................ c038aba0 3d050000 04000000 ccbf28c0 74130000 =.........(.t... c038abb0 01000000 f0bf28c0 74130000 02000000 ......(.t....... ... You should be able to use sprintf() at this stage in the boot, you can use it to print values to a buffer then pass it to your KW_PUTS() function. It is linking fine for me, how are you building the kernel ? Robert Swindells </pre> Robert Swindells 2012-05-23T16:35:52 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3373 <pre> Hi Nick, I'm confused by this, too. I'm not sure exactly what I'm looking for. objdump -D marvell_macdep.o shows me: 00000000 &lt;consinit_called.9907&gt;: 0: 00000000 andeq r0, r0, r0 readelf -x .data marvell_macdep.o shows the same: Hex dump of section '.data': 0x00000000 00000000 00c20100 004b0000 00000000 .........K...... 0x00000010 00000000 0000ffff Just to be clear, I'm reading these as consinit_called.9907 lives in offset 0 relative to .data (and I presume the .9907 is gcc's invented ID, because it differs from a previous compilation). So consinit_called in marvell_macdep.o has all bytes initially 0. That obviously differs from the behaviour I'm seeing at runtime. How can I inspect netbsd.bin? I'd like to confirm that this object ends up there with all bytes 0, too. Other than that, I have absolutely no idea what to investigate next. Is this a bug in linking? Surely not. Do you mean before initarm? Thanks, </pre> Kate F 2012-05-23T15:41:51 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3372 <pre>Hi again, 2012/5/23 Dave Burgess &lt;burgess&lt; at &gt;cynjut.com&gt;: Ohh, I see. So, I would recommend that you flash a new version of U-Boot onto the Mini2440. First start off by trying U-Boot from RAM (following the description in "Run U-Boot without flashing it to NAND"). Unfortunately, you will need a tool, which to me best knowledge is only available on Linux and Windows. It's called DNW for Windows and USBPush (Boot USB) for Linux, and is available from http://www.friendlyarm.net/downloads. You might be able to do xmodem transfer as well to Supervivi, but I haven't tried that myself. If U-Boot from ram seems to work fine for you, you can follow the instructions outlined in "Flashing U-Boot to NAND" to get it into NAND. Alternatively, U-Boot can also be used to place U-Boot in NAND, as described in section "Loading / Flashing the first U-Boot" at http://code.google.com/p/mini2440/wiki/MiniBringup. I hope this helps you. Best regards, Paul </pre> Paul Fleischer 2012-05-23T06:42:01 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3371 <pre> I'm a bit confused by this. This page [1] says the RAM for the DNS-325 is provided as two chips: 2xSEC K4T1G084QF-HCF7:128Mx8 &lt; at &gt;400 CL6 (256MB total) From dmesg of Linux on a SheevaPlug [3] (which I presume is the same as yours): SDRAM_CS0 ....base 00000000, size 256MB SDRAM_CS1 ....base 10000000, size 256MB SDRAM_CS2 ....disable SDRAM_CS3 ....disable And U-boot: DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 DRAM CS[0] base 0x00000000 size 256MB DRAM CS[1] base 0x10000000 size 256MB DRAM Total size 512MB 16bit width But dmesg of the Linux in the origional DNS-325 firmware [2] confusingly shows the same: SDRAM_CS0 ....base 00000000, size 256MB SDRAM_CS1 ....base 10000000, size 256MB SDRAM_CS2 ....disable SDRAM_CS3 ....disable And U-boot shows what I'd expect: DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 DRAM CS[0] base 0x00000000 size 256MB DRAM Total size 256MB 16bit width I don't understand why Linux's dmesg on both machines would report the same configuration, yet U-boot on each machine agrees with what I understand the hardware to be. In any case, NetBSD on my DNS-325 configures CS0 and CS1, just as Linux appears to. I don't understand it, but I think this is correct. The loop you mention in initarm() skips blocks of size 0 (in my case CS2 and CS3). I modified it as you suggest to also skip CS1: for (cs = MARVELL_TAG_SDRAM_CS0; cs &lt;= MARVELL_TAG_SDRAM_CS3; cs++) { mvsoc_target(cs, &amp;target, &amp;attr, &amp;base, &amp;size); if (size == 0) continue; if (cs == MARVELL_TAG_SDRAM_CS1) { KW_PUTS("skipping CS1\r\n"); continue; } ... } The call to consinit was made before this loop (which hints to me that this loop isn't at fault), and so I moved the call to consinit to occur after this loop. consinit_called still has its static storage starting out as non-zero, and so consinit still believes it has been called already, just as with the loop setting up both CS0 and CS1 as it was originally. [1] http://jamie.lentin.co.uk/devices/dlink-dns325/ [2] http://dns323.kood.org/dns-325 [3] http://nozell.com/blog/2009/05/13/sheevaplug-initial-bootlog/ </pre> Kate F 2012-05-23T04:24:52 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3370 <pre>I started out at the Mini2440 page you recommended. I understand everything until you say "From the U-Boot Prompt". The only thing I've found that sounds like a U-Boot prompt has all of the text entirely in Chinese, which is why I'm apparently unable to get started. The rest of the steps seem straightforward enough - I just can't figure out how to get to U-Boot. </pre> Dave Burgess 2012-05-22T22:34:46 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3369 <pre>[...] The data section should be read as is from the boot file into memory. As it's a .space and not .zero then it's probably getting filled by the linker with whatever the linker thinks the fill is for the data output section. You could check the kernel directly. bss is initialised after initarm here http://nxr.netbsd.org/xref/src/sys/arch/arm/arm32/locore.S#67 Nick </pre> Nick Hudson 2012-05-22T15:39:32 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3368 <pre> Kate F wrote: [snip] A current kernel boots fine on my Sheevaplug with the same SoC. From what I can see on the web, the only real difference between the DNS-325 and a Sheevaplug is that your D-Link device only has one bank of DRAM fitted. You could try modifying the code in initarm() that sets up the bootconfig structure to just set up one dram block. Robert Swindells </pre> Robert Swindells 2012-05-22T14:35:39 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3367 <pre>Hi all, I'm using NetBSD-current on a D-Link DNS-325 NAS. It's a Marvell Kirkwood 88F6281, which appears to be supported by the evbarm port according to the kernel source. My problem is a hang when booting. I've made myself a kernel using the sys/arch/evbarm/conf/DNS323 configuration. The DNS-323 is actually a different SoC, but I believe this is discovered by mvsoc_model(), and I can confirm that kirkwood_intr_bootstrap() is called. In other words, I think makeoptions BOARDTYPE="dns323" and options EVBARM_BOARDTYPE=dns323 are not actually used, and therefore that using the DNS323 on a 325 machine is okay. Booting from U-boot: Marvell&gt;&gt; tftpboot 2000000 netbsd.gz.ub; bootm 2000000 [snip] Bytes transferred = 2117011 (204d93 hex) ## Booting image at 02000000 ... Image Name: NetBSD/dns323 6.99.7 Created: 2012-05-21 22:17:58 UTC Image Type: ARM NetBSD Kernel Image (gzip compressed) Data Size: 2116947 Bytes = 2 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Transferring control to NetBSD stage-2 loader (at address 00008000) ... [silence] Poking around in sys/arch/evbarm/marvell/marvell_machdep.c I found the hang occurs on the first printf(). I presume because consinit() is not yet called. So I borrowed some code to let me write to the serial port directly, and I'm using that for debugging: #define KW_UART0 (0xf1012000) #define KW_THR (0x0) #define KW_LSR (0x14) #define KW_LSR_THRE (0x1&lt;&lt;5) /* Transmit enable */ #define KW_DBG(c) \ do { \ volatile uint8_t *kw_base = (uint8_t *) KW_UART0; \ while ((kw_base[KW_LSR] &amp; KW_LSR_THRE) == 0) \ ; \ kw_base[KW_THR] = (uint8_t)(c); \ } while (0) #define KW_PUTS(s) \ do { \ const char *kw_p; \ for (kw_p = (s); *kw_p; kw_p++) { \ KW_DBG(*kw_p); \ } \ } while (0) Scattering a few calls to that in marvell_machdep.c, for the first call to consinit: ... KW_PUTS("H CONSINIT BEING CALLED\n\r"); consinit(); KW_PUTS("I CONSINIT DONE\n\r"); ... And inside consinit: void consinit(void) { static int consinit_called = 0; if (consinit_called != 0) { KW_PUTS("CI 0 called already\n\r"); return; } consinit_called = 1; ... } Prints the following on boot: ## Transferring control to NetBSD stage-2 loader (at address 00008000) ... H CONSINIT BEING CALLED CI 0 called already I CONSINIT DONE So here I presume consinit_called isn't having its static storage initialised to 0, as I would expect. nm marvell_machdep.o says consinit_called does indeed live in the data segment: 000004a4 T consinit 00000000 d consinit_called.9898 And gcc's marvell_machdep.s corresponds: .data .align 2 .set .LANCHOR0,. + 0 .type consinit_called.9898, %object .size consinit_called.9898, 4 consinit_called.9898: .space 4 So I believe the data segment is not being initialised correctly. Unfortunately this is where I fall short; I have no idea where to look next, or what to do about it. Any suggestions, please? Incidentally, gcc is compiling with -fno-zero-initialized-in-bss which I presume is correct, because (I think) the bss initialisation is done by the kernel during load. Is that right? Thanks, </pre> Kate F 2012-05-22T12:42:49 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3366 <pre>Hi Dave, 2012/5/21 Dave Burgess &lt;burgess&lt; at &gt;cynjut.com&gt;: I have a couple of tips and tricks on how to get started with NetBSD on the MINI2440 at http://xpg.dk/projects/netbsd-support-for-the-mini2440/nb-mini2440-ht/ If that does not help you, please let me know so that we can get you up and running (and correct/extend the page). Best regards, Paul </pre> Paul Fleischer 2012-05-21T21:04:10 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3365 <pre>I normally lurk on current-users,. but saw a message from this group and thought I'd bother you for a minute. I've recently started trying to build a new prototype for my "room status" device. It going to be doing a bunch of stuff, and I've recently purchased a Mini2440 as the processor of choice for the actual implementation. I'm having trouble getting started installing/netbooting NetBSD on the thing. Most of the programs that come with this beast are in Chinese, which would be OK if I read Chinese..... I've got the TFTP directory set up and ready to use (I already use it for netbootking diskless workstations and phones) and have (I think) all of the software I need to get it working. If anyone has any experience setting these things to light, I'd love to hear about it. </pre> Dave Burgess 2012-05-21T15:58:37 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3363 <pre>Le 7 mai 2012 à 14:48, Jonathan A. Kollasch a écrit : erf... I don't know the soldering way :-/ I already did the "restore stock" procedure. http://buffalo.nas-central.org/wiki/Revert_Buffalo_Linkstation_Mini_To_Stock_Firmware What it did, AFAIK, was force the box to fetch some bits via TFTP. Then, those fetched bits grabbed some more to reinstall the box properly. If I can have the box fetch "bootmini2440", will it automatically try to find some NetBSD kernel or will it drop to prompt and wait until I issue "dhcp" and "go" commands ; as seen here (http://xpg.dk/nb-mini2440-ht/) ? That way I could prepare a remote NFS install. Sorry, I thought it was better to shortened them. Thanks. </pre> Joel Carnat 2012-05-07T14:06:12 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3362 <pre> It's not the CPU core to worry about, it's the SoC. (Though there are possibly some CPU cores we don't already support.) However, the 88F5182 SoC is already supported. Unknown, but should be easy to add support. With serial console it should be somewhat straightforward to figure out where the kernel can be placed in RAM. My HP MV2120 (based on a similar SoC) can boot from ext2fs on internal disk (albeit much more slowly than it should). It tends to vary a bit with the particular U-Boot in flash. Essentially it comes down to loading a compatible-with-your-board-and-version-of-UBoot kernel uImage. You probably want to netboot the initial test kernels. You will want 3V3 TTL serial port access to start testing kernels. Jonathan Kollasch P.S. Please just use the unobscured URLs. </pre> Jonathan A. Kollasch 2012-05-07T12:48:35 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3361 <pre>Hello, I'm looking at modding my Buffalo Linkstation Mini (http://goo.gl/25bec). Before using Linux Debian on it, I wanted to know if NetBSD supports this motherboard. According to there (http://goo.gl/3dFv0), the ARM926EJ would be supported. What is the support status for this board ? If supported, can it boot from internal disks ? And if so, is there some notes available somewhere that explains the installation process ? Thanks, Jo </pre> Joel Carnat 2012-05-07T12:28:56 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3360 <pre> Hubert Feyrer wrote: The SoC seems reasonably well documented, apart from the display controller of course. It seems to have an unusual startup sequence though with no firmware to load the Linux kernel. Robert Swindells </pre> Robert Swindells 2012-05-05T13:28:25 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3359 <pre> What's the chance of seeing NetBSD on a Raspberry Pi? It has a Broadcom BCM2835 SoC that includes a 700MHz ARM1176JZF-S CPU core and some other nice stuff - see details e.g. at http://www.techspot.com/review/527-raspberry-pi/ - Hubert </pre> Hubert Feyrer 2012-05-05T12:29:24 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3358 <pre>Hi, I have purchased two Gumstix OVERO COMs (Tide and Water) and a Gumstix board (Tobi). I am having trouble booting NetBSD-current on these, has anyone got recent experience of doing this? Below is a console dump whilst booting the OVERO Tide. Nothing is displayed after passing control to the kernel. From looking at mailing list archives, I am expecting the following: NetBSD/evbarm (overo) booting ... I can confirm that code in gumstix_start.S does start to execute. By inserting code to print to the console I can confirm that it runs until it flushes the TLB and sets the TTB. I managed to print the following diagnostic details just before the TLB flush. Interpretation of the register values has been done by hand, most of it makes sense except for the control register suggesting that the MMU is already turned on? Kernel Start: 0x80200000 RAM size: 0x20000000 Boot Arg[0]: 0x9ff27fe0 Boot Arg[1]: 0x00000000 Boot Arg[2]: 0x9ffb482a Boot Arg[3]: 0x9ffb482a Processor ID: 0x411fc083 [31:24] Implementor = 0x41 ARM [23:20] Major revision = 0x1 [19:16] Architecture = 0xF [15:4] Primary part = 0xC08 Cortex-A8 [3:0] Revision = 0x3 Status Reg: 0x600001d3 Z, C, A, I, F, Mode=0x13 Z = Zero C = Carry A = Disable imprecise data aborts I = IRQ interrupts are disabled F = FIQ interrupts are disabled Mode = Supervisor Control Reg: 0x00c5187b V = 0 = Normal exception vectors selected I = 1 = instruction caching enabled Z = 1 = program flow prediction enabled C = 0 = data caching disabled at all levels A = 1 = strict alignment fault checking enabled M = 1 = MMU enabled TTB Reg: 0x9fff0000 Domain Reg: 0xffffffff thanks for any help you can provide Michael. -- Texas Instruments X-Loader 1.5.0 (Aug 29 2011 - 12:52:49) No NAND detected OMAP3530-GP ES3.1 Board revision: 1 Reading boot sector Loading u-boot.bin from mmc U-Boot 2010.12 (Aug 22 2011 - 09:49:35) OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 mHz Gumstix Overo board + LPDDR/NAND I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment In: serial Out: serial Err: serial Board revision: 1 Direct connection on mmc2 No EEPROM on expansion board Die ID #09b20004000000000403951c07012007 Net: smc911x-0 Hit any key to stop autoboot: 0 Overo # mmc init Overo # mmc part 0 Partition Map for MMC device 0 -- Partition Type: DOS Partition Start Sector Num Sectors Type 1 128 130944 c 2 131072 3731456 83 Overo # fatls mmc 0:1 / 24240 mlo 235252 u-boot.bin 2914772 uimage 1586112 netbsd.gz.ub 3378688 netbsd.bin 5 file(s), 0 dir(s) Overo # fatload mmc 0:1 ${loadaddr} netbsd.gz.ub reading netbsd.gz.ub 1586112 bytes read Overo # bootm ${loadaddr} ## Booting kernel from Legacy Image at 82000000 ... Image Name: NetBSD/overo 6.99.4 Image Type: ARM NetBSD Kernel Image (gzip compressed) Data Size: 1586048 Bytes = 1.5 MiB Load Address: 80200000 Entry Point: 80200000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Transferring control to NetBSD stage-2 loader (at address 80200000) ... </pre> Michael Taylor | Omniscient 2012-04-14T07:19:01 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3357 <pre>Thank you for your comments. I've commited the list as evbarm/conf/README.evbarm. kiyohara&lt; at &gt; wrote: Updated "Gumstix Inc. PXA255/270 based boards" Yes, thanks. Also updated "Gumstix Inc. OMAP3530 based Overo boards" macallan&lt; at &gt; wrote: If it works on single user we always claim "it runs" so it's okay to have the entry. It's also enough if it has an own driver. --- Izumi Tsutsui </pre> Izumi Tsutsui 2012-04-07T01:45:05 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3356 <pre>I have committed tha patch. Thank you for the review. At Fri, 30 Mar 2012 07:50:49 -0400, Michael wrote: </pre> bsh< at >grotto.jp 2012-04-04T07:28:25 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.netbsd.ports.arm