Proposed patchset to support DreamPlug on freebsd 9 and 10.

Tue Nov 13 09:46:04 UTC 2012

I have just compiled and run a freebsd-current with a patchset I found on http://jessewhite.ca/dreamplug-freebsd/ on a dreamplug which starts with serialnumber DS2-1213.

According to the discussion on the FreedomBox mailinglist there seem to be different varieties depending on the first four digits of the serial number. I bought mine in july 2012, direct from GlobalScale. It came with a 4 GB SDHC card. 

I use the internal card, formatted with a fat and a ufs partition. 

I used the latest Freebsd-current (12-nov-2012) as a base system, apparently with clang as a compiler. I then gitted the freebsd tree from github into /usr/local/src/bsdcode/freebsd, to make it easier to differentiate between the /usr/src/ 'prodcution' tree and the /usr/local/src/bsdcode/freebsd 'arm test' tree.

All I did was twiddle with the kernel config file to replace the ZERO_COPY_SOCKETS option that is now replaced by SOCKET_SEND_COW and   SOCKET_RECV_PFLIP, and remove the IPFIREWALL_FORWARD option, which is now always compile in. 

#removed in freebsd10
#options        IPFIREWALL_FORWARD

# eliminating data copies on socket reads and writes.
# man 9 zero_copy
#options                ZERO_COPY_SOCKETS
#bsd 10
options                 SOCKET_SEND_COW
options                 SOCKET_RECV_PFLIP

and made sure the root was internally.

options         ROOTDEVNAME=\"ufs:/dev/da0s2\"

I have a few problems:

First:
I am getting errors from the sdhc driver:

errors like
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 0 0 16 6 6f 0 0 40 0 
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command

are popping up all the time in the console (I have a JTAG console via screen /dev/ttyU1 115200)

Second:

the ethernet addresses do not seem to be recognized by the kernel:

root at dreamplug-bsd:~ # ifconfig -a

mge1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
        ether 00:00:00:00:00:00
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active

I'd be happy to help to find out which dts files have to be used for which dreamplug, and how we can make sure this thing will be a first class FreeBSD citizen.

On 13 nov. 2012, at 08:38, Mattia Rossi <mattia.rossi.mailinglists at gmail.com> wrote:

> Am 12.11.2012 19:04, schrieb Ian Lepore:
>> On Mon, 2012-11-12 at 17:37 +0100, Mattia Rossi wrote:
>>> Am 12.11.2012 16:02, schrieb Ian Lepore:
>> ...
>>>> 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.
>> I bricked it in the dumbest possible way: I typed a command into the
>> wrong window.  I'm trying to get freebsd's nand support ported to an
>> embedded system for work, and I was using the DP as a reference
>> implementation, and I did a dd command to write to the nand in the DP's
>> console window instead of the console for the embedded system.
>> 
>>> 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.
>> The jtag interface on the DP is a pretty marginal thing... you can't
>> just connect to it with OpenOCD and reflash or even load a boot image
>> like you should be able to.  Marvell and/or globalscale seem to have
>> gotten some things wrong; there's quite a bit of info about this if you
>> google.  I did manage to get the DP's attention with OpenOCD a couple
>> times, using the technique of carefully timing the launch of the openocd
>> script with manually hitting the power button.  If you're lucky you can
>> occasionally hit the 50ms or so window during which it will respond.
>> But then I still couldn't do anything after getting the right prompt.
>> 
>> Another problem is that I can't even find the right image to flash
>> because globalscale's site indicates that all DP units contain NOR
>> flash, not NAND.  If I can ever get past the jtag timing glitches, I'm
>> hoping the NAND image for a GuruPlug will work.
>> 
>> 
> Wow, okay, didn't know about this problem. This sucks...
> As said, at the moment I'm not able to do anything, but as my dreamplug is NAND and everything on it is intact, I might simply revert to ubuntu to get an image of the uboot, so at least that should help. So we can archive that somewhere for safety.
> 
> Hope to be able to do that within a month or so, but can't guarantee that.
> 
> Cheers,
> 
> Mat
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

Johan Henselmans
johan at netsense.nl