1 Reply by Damien Miller

(6 replies, posted in Software)

First, a general update:

USB does work, but the USB-attached ethernet AX88772B doesn't. I suspect a GPIO needs flipping or a driver bug.

The I.MX ethernet is now working reliably on the latest kernels, but I'm not sure whether these fixes have made it into a released snapshot yet.

It's quite reliable on SSD and is able to fully rebuild the kernel+userland.

In answer to your questions:

sdcard access from OpenBSD (either internal or external) isn't working yet unfortunately. I haven't figured out why, but it's probably a GPIO thing again.

To get OpenBSD working, you could download bsd.rd.IMX.umg to /boot on the internal sdcard or boot via TFTP. Attach either a SSD or a USB stick to install too and run the commands I originally posted to load and run the installer kernel. You should be able to complete an install to SSD or a USB drive at present (assuming the I.MX ethernet fixes are in the snapshot otherwise it will be slow and flaky).

If you install to SSD then you can create a small FAT filesystem and you'll be able to load u-bootified kernels directly off it. If you install to a USB stick, you'll have to mule the kernels back to the internal sdcard's /boot via Linux until one of us gets the sdcard support unbroken.

As far as helping with porting, there's still heaps to do:

i2c is flaky and is needed to get to the eeprom with display config to write a wsdisplay driver to get the screen working (only three steps in this yak shave). There's a small AX25 EEPROM driver in bitrig that could be modified for the 2nd step. Bitrig also has a better I2C driver, but I didn't manage to get it working reliably.

The sdcard and AX ethernet problems need to be figured out.

There are quite a few I2C drivers that could be written, e.g. for the MEMS gyro/accellerometer and various other things.

PCIe needs to be got working

A lot of problems would be easier if OpenBSD had good FDT support...

Longer-term goals: SMP, FPGA kernel driver, X11

Go to forum: Software

2 Reply by Damien Miller

(2 replies, posted in Software)

nevermind - found it. The skew values are poked in via the FDT. Copying them into a hacked-up version of FreeBSD's micphy.c driver (since OpenBSD doesn't yet have FDT support) to poke them into the phy gives me stable net.

Go to forum: Software

3 Topic by Damien Miller

(2 replies, posted in Software)

Hi,

I'm trying to figure out why the FEC ethernet is flaky on OpenBSD. http://www.kosagi.com/w/index.php?title … _every_day lists some tweaks that were needed to make the it work properly, but I can't see any sign they were integrated to the kernel. Did they get merged, or were they fixed in hardware?

-d

Go to forum: Software

4 Topic by Damien Miller

(6 replies, posted in Software)

FYI, the latest snapshot releases of OpenBSD will boot on Novena. It's still very rough: no SMP, flaky USB and support for the eeprom (so no MAC addr on the IMX ethernet), but it gets to multi-user and could probably compile its own kernel given the chance.

Jonathan Grey did the work of preparing a kernel configuration for Novena and fixing the memory handling bugs that prevented it from booting.

http://pastebin.com/raw.php?i=dr2qZSi2 is a boot log

To try it out, the easiest way is to setup tftp server and configure DHCP to tell Novena about it. Then boot/reset with the user button held down, ^C when prompted and issue the following u-boot commands:

setenv machid 10ad
setenv loadaddr 0x10800000
dhcp
bootm

Note that u-boot doesn't seem to fully reset the ethernet controller/MAC. If you experience partial transfers that abort due to timeouts during the 'dhcp' command then a workaround is to completely remove power from Novena and try again after a minute or three.

If you get OpenBSD installed, to keep it booting you'll need to put a copy bsd.*IMX.umg on the sdcard's /boot partition via Linux (OpenBSD can't access the sdcard yet) and adjust u-boot to fatload it. Something like:

setenv machid 10ad
setenv loadaddr 0x10800000
fatload mmc 0 0x10800000 bsd.IMG.umg
bootm

Will get it going.

Go to forum: Software

5 Reply by Damien Miller

(12 replies, posted in Firmware)

I finally found some time to work on this. It turns out that I did need to update the SPL. BTW it seems that novena-install-spl isn't included as part of the .deb, but I found it in the repository.

With the SPL updated and the u-boot.img built from the tip of novena-r2, ethernet is back to working, but is still a bit flaky.

It seems that the flakiness manifests if Linux has booted and the novena has been reset, so I expect it's not being cleanly initialised. A simple workaround is to remove the power for a little while if Linux has booted.

"mii dump" shows no difference between a failing and working ethernet unfortunately sad

Go to forum: Firmware

6 Reply by Damien Miller

(12 replies, posted in Firmware)

No, that seems to have busted Ethernet entirely. It seems to think it it is up, but nothing sent appears on the wire.

Reverting 9ca708b134496815579dcbba2be1607d8a2f556f doesn't make any difference - the NIC status light don't come on either.

BTW, do I need to install either the SPL or spl/u-boot.spl.bin files to /boot/u-boot.spl?

Go to forum: Firmware

7 Reply by Damien Miller

(12 replies, posted in Firmware)

Oh, and tftpboot is still flaky. It works if I let Linux boot first and then reboot, so I guess it's missing some MII magic

Go to forum: Firmware

8 Reply by Damien Miller

(12 replies, posted in Firmware)

By "older kernels" do you mean the one that's installed by default?

Go to forum: Firmware

9 Reply by Damien Miller

(12 replies, posted in Firmware)

Thanks - I'll try the new bootloader. Are the instructions the same? Anything special that needs to happen to upgrade from the old one?

Go to forum: Firmware

10 Reply by Damien Miller

(12 replies, posted in Firmware)

Actually, 10baseT half-duplex works acceptably as a workaround. It probably is autoneg-related

Go to forum: Firmware

11 Topic by Damien Miller

(12 replies, posted in Firmware)

Hi,

I'm helping Jonathan Gray try to get OpenBSD running on Novena, and noticed that tftpboot is pretty unreliable - it gets frequent network timeouts and will often exceed u-boot's failure counter and attempt the download again.

I'm pretty sure it's not autoneg getting the duplex wrong, and dropping the peer to 100baseTX or 10baseT doesn't seem to help either. Any clues?

Also, is it possible to increase the grace period to hit ^c to get to the uboot menu? It's pretty short to go from the two-finger user+reset press to the keyboard in time. I guess I need to rebuild u-boot.img - are the instructions at http://www.kosagi.com/w/index.php?title … _PVT_Notes still up to date? It looks like recent u-boot commits have been in a different repository (/xobs/u-boot-novena)

-d

Go to forum: Firmware

12 Topic by Damien Miller

(1 replies, posted in Firmware)

Hi,

Is the firmware in the desktop Senoko passthrough board the same as the full battery controller? It's https://github.com/xobs/senoko-chibios-3, right?

Is there a guide to getting a working toolchain/build environment for it anywhere? The GPIO headers look handy, since the mainboard doesn't have too many exposed if the high-speed slot is otherwise occupied (e.g. with MyriadRF).

Thanks,
Damien

Go to forum: Firmware

13 Reply by Damien Miller

(3 replies, posted in Hardware)

I had a pair on u.fl laptop antennas laying around that had cables that were of decent length, something like this: http://www.ebay.com/itm/New-Pair-of-PCI … 1110158624

Mine are affixed ~15cm apart to the plastic backing of the LCD panel.

Go to forum: Hardware

14 Topic by Damien Miller

(1 replies, posted in Software)

Hi,

I just received my desktop yesterday and the out-of-box software experience was completely seamless - well done!

One small irritation, if I bump the case while it is open then xscreensaver frequently activates in lock mode. I assume that this is the lid switch sensor being a bit over-sensitive. It's easy enough to turn off for now via xfce's settings menu -> power management -> Laptop lid, set to "switch off display". I guess power management is not implemented for the internal display yet.

Is there any way to unplumb the lid switch event short of physically disconnecting the sensor?

Thanks,
Damien

Go to forum: Software