d3e53912d2
pci_find_rom(), pci_intr_map(9), pci_enumerate_bus(), nor the match predicate passed to pciide_compat_intr_establish() should ever modify their pci_attach_args argument, so make their pci_attach_args arguments const and deal with the fallout throughout the kernel. For the most part, these changes add a 'const' where there was no 'const' before, however, some drivers and MD code used to modify pci_attach_args. Now those drivers either copy their pci_attach_args and modify the copy, or refrain from modifying pci_attach_args: Xen: according to Manuel Bouyer, writing to pci_attach_args in pci_intr_map() was a leftover from Xen 2. Probably a bug. I stopped writing it. I have not tested this change. siside(4): sis_hostbr_match() needlessly wrote to pci_attach_args. Probably a bug. I use a temporary variable. I have not tested this change. slide(4): sl82c105_chip_map() overwrote the caller's pci_attach_args. Probably a bug. Use a local pci_attach_args. I have not tested this change. viaide(4): via_sata_chip_map() and via_sata_chip_map_new() overwrote the caller's pci_attach_args. Probably a bug. Make a local copy of the caller's pci_attach_args and modify the copy. I have not tested this change. While I'm here, make pci_mapreg_submap() static. With these changes in place, I have tested the compilation of these kernels: alpha GENERIC amd64 GENERIC XEN3_DOM0 arc GENERIC atari HADES MILAN-PCIIDE bebox GENERIC cats GENERIC cobalt GENERIC evbarm-eb NSLU2 evbarm-el ADI_BRH ARMADILLO9 CP3100 GEMINI GEMINI_MASTER GEMINI_SLAVE GUMSTIX HDL_G IMX31LITE INTEGRATOR IQ31244 IQ80310 IQ80321 IXDP425 IXM1200 KUROBOX_PRO LUBBOCK MARVELL_NAS NAPPI SHEEVAPLUG SMDK2800 TEAMASA_NPWR TEAMASA_NPWR_FC TS7200 TWINTAIL ZAO425 evbmips-el AP30 DBAU1500 DBAU1550 MALTA MERAKI MTX-1 OMSAL400 RB153 WGT624V3 evbmips64-el XLSATX evbppc EV64260 MPC8536DS MPC8548CDS OPENBLOCKS200 OPENBLOCKS266 OPENBLOCKS266_OPT P2020RDB PMPPC RB800 WALNUT hp700 GENERIC i386 ALL XEN3_DOM0 XEN3_DOMU ibmnws GENERIC macppc GENERIC mvmeppc GENERIC netwinder GENERIC ofppc GENERIC prep GENERIC sandpoint GENERIC sgimips GENERIC32_IP2x sparc GENERIC_SUN4U KRUPS sparc64 GENERIC As of Sun Apr 3 15:26:26 CDT 2011, I could not compile these kernels with or without my patches in place: ### evbmips-el GDIUM nbmake: nbmake: don't know how to make /home/dyoung/pristine-nbsd/src/sys/arch/mips/mips/softintr.c. Stop ### evbarm-el MPCSA_GENERIC src/sys/arch/evbarm/conf/MPCSA_GENERIC:318: ds1672rtc*: unknown device `ds1672rtc' ### ia64 GENERIC /tmp/genassym.28085/assym.c: In function 'f111': /tmp/genassym.28085/assym.c:67: error: invalid application of 'sizeof' to incomplete type 'struct pcb' /tmp/genassym.28085/assym.c:76: error: dereferencing pointer to incomplete type ### sgimips GENERIC32_IP3x crmfb.o: In function `crmfb_attach': crmfb.c:(.text+0x2304): undefined reference to `ddc_read_edid' crmfb.c:(.text+0x2304): relocation truncated to fit: R_MIPS_26 against `ddc_read_edid' crmfb.c:(.text+0x234c): undefined reference to `edid_parse' crmfb.c:(.text+0x234c): relocation truncated to fit: R_MIPS_26 against `edid_parse' crmfb.c:(.text+0x2354): undefined reference to `edid_print' crmfb.c:(.text+0x2354): relocation truncated to fit: R_MIPS_26 against `edid_print' |
||
---|---|---|
.. | ||
nslu2_buttons.c | ||
nslu2_iic.c | ||
nslu2_leds.c | ||
nslu2_machdep.c | ||
nslu2_mainbus.c | ||
nslu2_pci.c | ||
nslu2_start.S | ||
nslu2reg.h | ||
README |
$NetBSD: README,v 1.7 2009/11/22 19:09:15 mbalmer Exp $ NetBSD for the Linksys NSLU2 (a.k.a. "Slug") ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The NSLU2 (Network Storage Link for USB 2.0 Disk Drives) is a small, cheap NAS device consisting of an Intel IXP420 (Xscale) CPU, a 10/100mbit Ethernet port, and two USB 2.0 ports. It has 32MB of SDRAM and 8MB of Flash memory, and runs RedBoot/Linux out of the box. It is eminently hackable. The guys over at http://www.nslu2-linux.org/ have done a good job of documenting just about every aspect of the hardware and original firmware. They also provide a custom "Unslung" Linux distribution to replace the original hobbled kernel/userland. Because of the amount of documentation available, and the fact that Slugs are available so cheaply (I paid just over UKP 50 for mine, brand new) I decided to buy one and port NetBSD to it. This is the result of that effort. Note: The Slug's IXP420 CPU runs in big-endian mode, so when building a cross toolchain you must pass "-m evbarm -a armeb" to build.sh. Current status ============== The following bits of Slug hardware are not (yet?) supported: - Flash ROM You can write gzboot kernels (when support is added) to Flash using RedBoot, so all is not lost. - Buzzer In the absence of a decent API to expose the onboard buzzer to userland, this is not yet supported. I envisage using timer1 to generate an interrupt at the required rate (1-2 kHz). The handler will toggle the buzzer GPIO pin. Obviously timer1 will be configured only when necessary as a 1-2 kHz interrupt rate will sap a fair bit of CPU horsepower. Everything else is fully supported, including the power/reset buttons and disk activity/status LEDs. Non-hardware items on the TODO list include: - gzboot support. The Slug's 8MB of Flash is split into 5 segments: 1 0x50000000-0x5003ffff: RedBoot (with some additional bits at the end). 2 0x50040000-0x5005ffff: Sysconf (used by the Linksys firmware). 3 0x50060000-0x5015ffff: Self-extracting compressed kernel image. 4 0x50160000-0x507dffff: Compressed ramdisk image. 5 0x507e0000-0x507fffff: SerComm Flash trailer. Segments 1, 2, and 5 should be considered immutable. Segments 3 and 4 have a 16-byte header, the first 4 bytes of which describe the length of the image contained in that segment (not including the header). On power-up, RedBoot copies the image in segment 3 into SDRAM at 0x01d00000, and the image in segment 4 into SDRAM at 0x01000000. RedBoot then jumps to 0x01d00000. This is just a regular ARM Linux compressed kernel bootloader. So, we need to create a version of gzboot linked not at Flash address 0x50060000, but at 0x01d00000 instead. The only downside is that it looks like the combined size of gzboot plus compressed kernel cannot exceed 1MB. To support an md(4) root filesystem, we will need to modify gzboot to decompress the ramdisk image from segment 4 and copy it to the correct place in the decompressed kernel image. - Move the kernel link address closer to the start of SDRAM. We waste a little under 2MB with the current setup. Getting NetBSD onto the NSLU2 ============================= Thanks to the efforts of the guys over at www.nslu2-linux.org, hacking the Slug is a pretty easy proposition, but some soldering skills are essential. For a first-time install of NetBSD (at least until someone comes up with a nice easy binary install image) you will almost certainly require access to the serial console. This means firing up your trusty soldering iron and hooking up a MAX3232 chip to your Slug. While your soldering iron is hot, you should seriously consider de-restricting your Slug's CPU core clock speed (133MHz stock, 266MHz de-restricted) by removing a single surface- mount resistor. Full instructions for both these mods are on the above website. Once you have console access you can interrupt RedBoot's auto-boot process using CTRL-C. You are now in a position to download a NetBSD kernel into SDRAM. You will have to configure a TFTP server on a machine hooked up to the same Ethernet segment as the Slug. This machine's Ethernet interface must also be configured to have an address in the 192.168.0.0/24 subnet since the Slug's Ethernet *always* defaults to 192.168.0.1 when running RedBoot. There seems to be no way to alter this, so the best course of action will probably be to set up an alias on the server's interface. 192.168.0.2 is a good choice. Assuming you've done all that and have dropped a suitable kernel image into the TFTP directory, the following commands will load and run the kernel. redboot> ip_address -h 192.168.0.2 redboot> load -r -b 0x200000 netbsd.bin redboot> go At this point you should mount a root filesystem from a USB disk device. The ethernet is now supported, so you may also be able to use a NFS root. USB Ethernet devices can also be used for a NFS root. Note that the kernel will always report the CPU core clock speed as 266MHz even if your Slug's CPU clock is running at a stock 133MHz. Burning a NetBSD kernel into Flash ================================== TBD (waiting for gzboot support).