Date: Mon, 12 Nov 2012 17:37:42 +0100 From: Mattia Rossi <mattia.rossi.mailinglists@gmail.com> To: freebsd-arm@freebsd.org Subject: Re: Proposed patchset to support DreamPlug on freebsd 9 and 10. Message-ID: <50A125D6.50508@gmail.com> In-Reply-To: <1352732526.1217.29.camel@revolution.hippie.lan> References: <CANuCnH_ZFiJCThSf5eCAzhZLOeZ769woHOrT9vTY9Dpo72Zgwg@mail.gmail.com> <1352732526.1217.29.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 12.11.2012 16:02, schrieb Ian Lepore: > On Mon, 2012-11-12 at 10:48 +0800, Alie Tan wrote: >>> After exchanging a few emails with Richard yesterday we realized why I >>> had to put some tweaks on top of the patches he had posted... there are >>> two different flavors of a DreamPlug v10. One of my co-workers has a >>> unit marked "1001" and it has NOR SPI flash, as does Richard's. My unit >>> is marked "1001N" and has NAND flash (which makes it a bit like an >>> expanded GuruPlug). >>> >>> This is going to drive the need for two separate .dts files and two >>> separate kernel configs. I reworked the patchset I've been using for >>> 9-stable and -current to move in this direction, and I'm attaching what >>> I've got so far as a proposal for handling this difference. >>> >>> The attached patches don't include Hiroki's led driver, this is just >>> minimal dreamplug support on top of a fresh checkout of 9 or 10. >>> >>> I've also heard there are differences in the v0901 dreamplug units, but >>> I don't know what the differences are. That might require yet another >>> set of config. >>> >>> I broke the kernel config into 3 pieces... a DREAMPLUG-BASE that has >>> config for things that are dreamplug-specific and common to all >>> dreamplugs, and notably is not a GENERIC or kitchen-sink type config >>> file. Then there are DREAMPLUG-1001 and -1001N config files that >>> include the -BASE file, and add other options to make a more fully >>> usable system. I think there's plenty of room for changes and additions >>> to these -1001[N] files, such as IPFW and other things that you might >>> want right out of the box -- I do mainly embedded systems work, so I >>> don't know what most folks might want. >>> >>> The config for the 1001N needs more work, notably more support for the >>> NAND flash in the .dts and kernel configs. Since the whole reason I'm >>> playing with a dreamplug is to get some experience using nand flash, >>> I'll be working on that in the days to come. I just wanted to get this >>> out there and see if folks think this is a workable direction for >>> supporting different dreamplug flavors. >>> >>> -- Ian >>> >> Is there any plan to merge this patch to HEAD? Its already 3 months but >> still now news about this news. >> >> Regards, >> Alie T > It's been long enough now that I'm not sure that patchset will even > apply cleanly anymore. I bricked my dreamplug and haven't been able to > revive it yet (I haven't quite given up, but that fact that's it's > almost a one-off by being NAND based doesn't help). I've worked around the risk of bricking it, by not touching the NAND at all, but by creating a FAT32 partition on the internal SD (or was it FAT16?), where the kernel resides. The installed uboot is quite happy to boot from there. You might want to try reinstalling the original uboot on the NAND using the JTAG. I'm sure I've seen the instructions for that somewhere on the net. This way we don't need the NAND/NOR crazyness for the dreamplug. It's not super clean, but with 2M of NAND in my dreamplug there's no space for a freebsd kernel anyway. Unless you need to touch the uboot loader on the NAND/NOR, you don't even need the NAND/NOR support for the dreamplug IMHO. Just talking about the dreamplug and about what to include in HEAD, not generally. > I just ordered a new dreamplug a few days ago; I assume I'm going to get > one with NOR flash this time. When it arrives I'll see about updating > and re-validating the patches and try to find someone who'll commit it > for us. > > I'd like to actually have a dreamplug replace the ancient x86 computer I > use for router and firewall and etc. This is what I wanted to achieve a while ago as well (including using it as WLAN hotspot, Router, Firewall, DNS server, IPv6 gateway and possibly even mailserver), but got interrupted for almost a year now. Will try to get back on track, once I've settled some more stuff. Maybe in 2/3 months time I can help again on this topic. > But that's essentially putting it > into "production," and even if that word may have a somewhat less > rigorous meaning when it's a server for a hacker, I still would be > happier if the support for it were part of freebsd. The last thing I > need when a problem happens (usually in the middle of trying to solve > two other problems) is trying to remember where I stashed some big > required patchset 2 years ago. > > Yes, it should definitely become part of FreeBSD, and easy to use. Cheers, Mat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50A125D6.50508>