http://permalink.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/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()</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 configurati</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: 00</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 [3</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 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3355 <pre> Right, I have tested x11 on NETWALKER and TWINTAIL. I'll try SMDK2410, LUBBOCK, and maybe BEAGLEBOARD, later. For 6.0, currently I have no plan to request pull-up. I'll do so if there is a big demand on it, but we'll need a little bit more work. BR bsh. </pre> Hiroyuki Bessho 2012-04-04T01:15:39 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3354 <pre>Hello, On Sat, 31 Mar 2012 12:04:37 +0900 Izumi Tsutsui &lt;tsutsui&lt; at &gt;ceres.dti.ne.jp&gt; wrote: ... OMAP's on chip USB controller doesn't work, so its usefulness right now is rather limited. What does work is video via HDMI, ( omapfb ), serial console, probably flash memory. Since this is based on the Beagle I suspect the same applies here. IIRC there's a driver for the onboard ethernet controller though. have fun Michael </pre> Michael 2012-04-02T01:11:59 http://permalink.gmane.org/gmane.os.netbsd.ports.arm/3353 <pre>Hi! Tsutsui-san, From: Izumi Tsutsui &lt;tsutsui&lt; at &gt;ceres.dti.ne.jp&gt; Date: Sat, 31 Mar 2012 12:04:37 +0900 GUMSTIX supports PXA255(Gumstix) and PXA270(Verdex) boards. Please fix to 'PXA2xx Gumstix board'. :-) ^ typo? :-) But don't support Overo *STORM now. *STORM boards works on TI Davinci. Not STORM works on TI OMAP35xx. Thanks, -- kiyohara </pre> KIYOHARA Takashi 2012-04-01T13:31:46 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.netbsd.ports.arm