Re: [opensuse-arm] Tumbleweed on Raspberry Pi 3 fails to boot in a weird way
Olav Reinert wrote: > Hi all, > > I want to run openSUSE Tumbleweed on a new Raspberry Pi 3 Model B+. > FWIW, installing a TW jeos image (without gui) works - except the wifi. There is a re-opened bugreport - 1127613. -- Per Jessen, Zürich (16.7°C) -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] keeping multiple kernels on ARM systems ?
Per Jessen wrote: > Matthias Brugger wrote: > >> Can you try if you put your custom dtb into >> /boot/dtb/current/ >> I suppose this directory does not get overwritten when updating the >> kernel. >> >> Would be nice to get feedback on this :) > > I'll see what I can do - I have a third nanopi that needs updating, I > think. Looking at boot.script from the jeOS image: http://download.opensuse.org/ports/armv7hl/distribution/leap/15.0/appliances/openSUSE-Leap15.0-ARM-JeOS-nanopineo.armv7l-2018.07.02-Buildlp150.1.1.raw.xz. it does not look at /boot/dtb/current. On my nanopis, I have hardcoded 'fdtfile' = 'sun8i-h3-nanopi-neo-air.dtb', but I see no search order, only one 'ftdfolder' (= /boot/dtb) -- Per Jessen, Zürich (15.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] keeping multiple kernels on ARM systems ?
Matthias Brugger wrote: > Can you try if you put your custom dtb into > /boot/dtb/current/ > I suppose this directory does not get overwritten when updating the > kernel. > > Would be nice to get feedback on this :) I'll see what I can do - I have a third nanopi that needs updating, I think. -- Per Jessen, Zürich (15.9°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
RE: [opensuse-arm] keeping multiple kernels on ARM systems ?
Guillaume Gardet wrote: > Hi, > >> -Original Message----- >> From: Per Jessen >> Sent: 19 April 2020 10:39 >> >> Question - the multiple kernels feature ought to have retained my dtb >> directory contents in /boot/dtb-4.12.14-lp150.12.48/ ? Or not ? > > AFAIK, there is no multiversion support for DTB. And DTB should even > be kernel version agnostic, but I know this is not really the case. > > Your /boot/dtb-4.12.14-lp150.12.48/ folder should have been dropped > (if there was no *.old file inside) and a new > /boot/dtb-4.12.14-lp150.12.82/ should have been created with the > update of your DTB package. Is it missing? Hi Guillaume 12.48 was not dropped as I had a file named *.old in there - I also had my working DTB in here, and that was gone. The new 12.82 directory only had the openSUSE supplied DTB which does not work (sufficiently well). I was happy when I noticed the 12.48 directory, thinking I can just quickly copy the old DTB over -- Per Jessen, Zürich (19.3°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] keeping multiple kernels on ARM systems ?
(repost from opensuse@o.o) I'm sure many have this feature enabled, just in case. Keeping multiple kernels and module versions around. On one of my ARM systems, yesterday I ran an update "zypper patch" (Leap 15.0), which installed a new kernel 4.12.14-lp150.12.82-lpae, the old one being 4.12.14-lp150.12.48-lpae. Both initrds were rebuilt, I have two kernels, two sets of modules - but my dtb was cleared out: /boot/dtb-4.12.14-lp150.12.48/ - empty apart from one file I had renamed to .old. I use my own DTB, but this did not prevent the system from booting, instead it did stop the network from coming up (wifi device not correctly defined in the openSUSE supplied DTB). I had to climb some 10meters up a ladder to retrieve the box, disassemble it and put a serial console on it :-) Question - the multiple kernels feature ought to have retained my dtb directory contents in /boot/dtb-4.12.14-lp150.12.48/ ? Or not ? -- Per Jessen, Zürich (17.3°C) -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] RE: video hardwar acceleration ? (was: where to find "vcgencmd" ?)
Per Jessen wrote: > Hmm. According to the MythTV wiki, it will use hw acceleration if > available, e.g. VDPAU (Nvidia) and the Intel VAAPI - does not mention > the Raspberry of course. Ah, I think need to change the "Painter" > setting to Auto. Hmm, did not work very well - maybe if I run MythTV > directly, instead of under icewm. I'll be back :-) Just a brief conclusion - I kept getting conflicting reports about the Raspi's ability to run MythTV with HDTV in a satisfactory manner. My own brief experience showed it was _slow_ just operating the MythTV menus, which I could tell was going to annoy me. Instead I switched to a Zotac mini PC I bought 3 years ago. Back then I gave up because I could not get hw accelerated video to work with Intel HD graphics. Seems to work fine now on Leap 15.1. -- Per Jessen, Zürich (11.3°C) -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] where to find "vcgencmd" ?
Stefan Seyfried wrote: > Am 12.12.19 um 10:47 schrieb Guillaume Gardet: > >>> -Original Message----- >>> From: Per Jessen > >>> Have just tried "Channel 4 HD", it reports HD1080, H264 - but it >>> stutters, it is not watchable. Clearly not accelerated which is >>> weird? >> >> AFAIK, only omxplayer was using video acceleration. >> https://pmbs.links2linux.de/package/show/Multimedia/omxplayer > vlc, gstreamer, vdr-plugin-rpihddevice all can use the hardware > acceleration. But AFAICT not on 64 bit systems (and I also seem to > remember not on upstream 32bit kernels). > > Were you ever able to use omxplayer on 64bit openSUSE raspi3? I had a look at it just now - I don't see any builds for Leap 15. -- Per Jessen, Zürich (4.9°C) -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] RE: video hardwar acceleration ? (was: where to find "vcgencmd" ?)
Guillaume Gardet wrote: >> -Original Message- >> From: Per Jessen >> Sent: 12 December 2019 10:42 >> To: opensuse-arm@opensuse.org >> Subject: Re: [opensuse-arm] where to find "vcgencmd" ? >> >> Stefan Seyfried wrote: >> >> > Am 12.12.19 um 10:03 schrieb Per Jessen: >> > >> >> I have TV working, that was straight forward, but it's definitely >> >> not hardware accelerated. >> > >> > Try with a HD channel (h264), that needs no extra license. >> >> Have just tried "Channel 4 HD", it reports HD1080, H264 - but it >> stutters, it is not >> watchable. Clearly not accelerated which is weird? > > AFAIK, only omxplayer was using video acceleration. > https://pmbs.links2linux.de/package/show/Multimedia/omxplayer Hmm. According to the MythTV wiki, it will use hw acceleration if available, e.g. VDPAU (Nvidia) and the Intel VAAPI - does not mention the Raspberry of course. Ah, I think need to change the "Painter" setting to Auto. Hmm, did not work very well - maybe if I run MythTV directly, instead of under icewm. I'll be back :-) -- Per Jessen, Zürich (4.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] where to find "vcgencmd" ?
Stefan Seyfried wrote: > Am 12.12.19 um 10:03 schrieb Per Jessen: > >> I have TV working, that was straight forward, but it's definitely not >> hardware accelerated. > > Try with a HD channel (h264), that needs no extra license. Have just tried "Channel 4 HD", it reports HD1080, H264 - but it stutters, it is not watchable. Clearly not accelerated which is weird? > But as I wrote, I could not get any of the video acceleration things > going with openSUSE kernels (I think I tried on the raspi 3, this is > when I noticed that the userland stuff will only build for 32bits) Okay - I guess it isn't so important, it was just a way of checking. -- Per Jessen, Zürich (4.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
RE: [opensuse-arm] where to find "vcgencmd" ?
Guillaume Gardet wrote: >> >> vcgencmd codec_enabled MPG2 >> >> I guess this is a Raspbian specialty - does anyone know where to find >> "vcgencmd" for openSUSE ? > > It is available in raspberrypi-userland package available for > Tumbleweed here: > https://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/RaspberryPi/standard/ > But it fails to build since end of September, so not sure if it is > still installable. Hmm, doesn't sound too promising. Thanks, I'll have a look. > But last time I tried, video decoding seemed to happen (no error) but > no image from the video were shown on HDMI output, only a black > screen. I have TV working, that was straight forward, but it's definitely not hardware accelerated. I have added the following to /boot/efi/extraconfig.txt : hdmi_force_hotplug=1 decode_MPG2=0x12345678 -- Per Jessen, Zürich (3.9°C) -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] where to find "vcgencmd" ?
On a Raspi 3B+ that I am preparing for MythTV (sofar it works fairly well), I'm trying to verify that the license for hardware MPEG2 decoding has been installed correctly - according to the mail from the Raspberry Pi Store, the command is: vcgencmd codec_enabled MPG2 I guess this is a Raspbian specialty - does anyone know where to find "vcgencmd" for openSUSE ? I see it here, but it's a 32bit executable, I guess I need some 32bit stuff for it to run? https://github.com/raspberrypi/firmware/blob/master/opt/vc/bin/vcgencmd thanks Per -- Per Jessen, Zürich (4.0°C) member, openSUSE Heroes. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] serial number of Raspberry Pi 3B+ ?
Matthias Brugger wrote: > Hi Per, > > On 10/12/2019 07:44, Per Jessen wrote: >> For the MPEG2 licensing, it seems I need the Raspi's internal >> 16-digit >> serial number - apparently available from /proc/cpuinfo. However, >> not with openSUSE: >> [snip] > > You should be able to read it out like this: > cat /proc/device-tree/serial-number Thanks, that's exactly where it was hiding :-) -- Per Jessen, Zürich (3.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] serial number of Raspberry Pi 3B+ ?
For the MPEG2 licensing, it seems I need the Raspi's internal 16-digit serial number - apparently available from /proc/cpuinfo. However, not with openSUSE: # cat /proc/cpuinfo processor : 0 BogoMIPS: 38.40 Features: fp asimd evtstrm crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part: 0xd03 CPU revision: 4 [snip] Where do I find it? -- Per Jessen, Zürich (2.8°C) -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
RE: [opensuse-arm] any hints for getting ds1820s to work with my nano pi neo air?
Guillaume Gardet wrote: >> For module 'w1-therm', I ended up adding 'strong_pullup=2' which >> reduced the number of bad readings, a lot. > > 1-wire should have CRC checksum to avoid wrong read. Yes, it does and the kernel module also checks and prints out a YES or a NO. Sometimes you still get a good reading (the CRC is good), but it reads 85000 which is the DS18x20 saying "poor communication". Yesterday since 1500, I have read 3 sensors once a minute, that is approx. 3000 readings. Of those, 73 had a bad crc, and 203 were bad readings (85000). That's actually pretty good, only 9% failure rate. I can possibly improve it with better cabling/routing. -- Per Jessen, Zürich (0.1°C) member, openSUSE Heroes -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
RE: [opensuse-arm] any hints for getting ds1820s to work with my nano pi neo air?
Per Jessen wrote:
>> You need to update your DTB, or create a fragment and merge it with
>> your current DT. Then, use this new DTB to boot your board.
>
> Right. It's good to get my suspicions confirmed, makes it easier to
> move in the right direction.
Thanks to Guillaume for getting me on the track. To those who might be
watching this thread - yes, it's working now!
Status: I'm reading three DS18x20 sensors connected to GPIO11. I'm
getting mostly good readings, but also quite a few bad ones (temp 85C).
I'll update the wiki-page as well as write an entry on my own blog, but
for those impatiently waiting -
I based everything on the DTB from the FriendlyCore eflasher image. It
has way more stuff than we have in the openSUSE JeOS ditto. I guess
the source is also available somewhere, but I started out with
decompiling to DTS.
a) Look for the entry "pinctrl@01c20800" and add a label 'gpio0:'
gpio0:pinctrl@01c20800
b) in this section, for instance above the 'csi' entry, add the
following:
ds1820_pins:w1_pins@0 {
label = "Dallas 1-wire";
pins = "PG11";
function = "gpio_in";
pull = <0x1>;
};
c) towards the end of the file, add this node:
onewire {
compatible = "w1-gpio";
pinctrl-names = "default";
pinctrl-0 = <&ds1820_pins>;
gpios = <&gpio0 0x0 203 0x1>;
status = "okay";
};
I added it after the "leds" node.
compile a new dtb:
dtc -b 0 -@ -I dts -O dtb your-new.dts >/boot/dtb/your-new.dtb
adjust your boot-script and reboot.
I am most certainly not very familiar with all of this, and it took a
lot of trial & error. Corrections and suggestions are very much
welcome.
For module 'w1-therm', I ended up adding 'strong_pullup=2' which reduced
the number of bad readings, a lot.
--
Per Jessen, Zürich (0.4°C)
http://www.dns24.ch/ - free dynamic DNS, made in Switzerland.
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
RE: [opensuse-arm] any hints for getting ds1820s to work with my nano pi neo air?
Guillaume Gardet wrote: > > >> -Original Message----- >> From: Per Jessen >> Sent: 25 November 2019 11:43 >> To: Guillaume Gardet ; opensuse- >> a...@opensuse.org >> Subject: Re: [opensuse-arm] any hints for getting ds1820s to work >> with my nano pi neo air? >> >> Guillaume Gardet wrote: >> >> >> I picked gpio11 because it happened to be convenient for the >> >> wiring, >> >> but I don't really care which one I use. What is the easiest way >> >> of using 1-wire devices on the nanopi, without having to modify >> >> the DTB >> >> ? I'm using the Friendlycore DTB, not the one from the openSUSE >> >> Jeos image. >> > >> > I fear that you need to update your DT. Not sure what is the >> > current status of Device Tree Overlays, upstream. >> [snip] >> > If device tree overlays are supported, you may just need to create >> > a dt fragment, compile it and load it at runtime or on boot as a >> > kernel option. >> >> Okay, I had almost concluded that myself, thanks for confirming it. >> Judging by the instructions for the Raspi, it seems overlays should >> be fine? > > On Raspberry Pi, the overlays are handled by firmware. So, this is > different. RPi is different from other boards. Yeah, that is certainly true, but I didn't know about that little twist. >> I'm going to go and study how to write a dt fragment for the nanopi. > > My understanding is upstream kernel, as used in openSUSE, cannot apply > DT overlays at runtime. Okay, good to know that I can ignore the overlay idea. > You need to update your DTB, or create a fragment and merge it with > your current DT. Then, use this new DTB to boot your board. Right. It's good to get my suspicions confirmed, makes it easier to move in the right direction. -- Per Jessen, Zürich (7.2°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] any hints for getting ds1820s to work with my nano pi neo air?
Guillaume Gardet wrote: I picked gpio11 because it happened to be convenient for the wiring, but I don't really care which one I use. What is the easiest way of using 1-wire devices on the nanopi, without having to modify the DTB ? I'm using the Friendlycore DTB, not the one from the openSUSE Jeos image. I fear that you need to update your DT. Not sure what is the current status of Device Tree Overlays, upstream. [snip] If device tree overlays are supported, you may just need to create a dt fragment, compile it and load it at runtime or on boot as a kernel option. Okay, I had almost concluded that myself, thanks for confirming it. Judging by the instructions for the Raspi, it seems overlays should be fine? I'm going to go and study how to write a dt fragment for the nanopi. -- Per Jessen, Zürich (7.1°C) Member, openSUSE Heroes. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
RE: [opensuse-arm] any hints for getting ds1820s to work with my nano pi neo air?
Guillaume Gardet wrote: > Hi, > >> -Original Message----- >> From: Per Jessen >> Sent: 24 November 2019 16:07 >> To: opensuse-arm@opensuse.org >> Subject: [opensuse-arm] any hints for getting ds1820s to work with my >> nano pi neo air? >> >> I measure temperature with DS1820 hooked up to microcontrollers (PIC) >> or via serial interface to regular PCs, now I was hoping to use a >> nanopi neo air, but I am not getting anywhere. >> >> I have the modules loaded - w1-therm, wire, w1-gpio - but no devices >> turn up in /sys/bus/w1/devices. I'm connecting the DS1820s to >> GPIO11 - I guess I need to modify the DTB to make this work? > > There are some information about 1-wire here: > https://en.opensuse.org/openSUSE:1-wire Thanks Guillaume, Yes, I've seen that one, but it's very limited :-) > If you want to use 1-wire on a regular gpio, with w1-gpio module, you > need to update your device-tree to setup it properly. Then, you can > check /sys/bus/w1/devices folder for any devices found on the 1-wire > bus. > > If you do not update your DTB, w1-gpio will not know which gpio to > use. I picked gpio11 because it happened to be convenient for the wiring, but I don't really care which one I use. What is the easiest way of using 1-wire devices on the nanopi, without having to modify the DTB ? I'm using the Friendlycore DTB, not the one from the openSUSE Jeos image. -- Per Jessen, Zürich (7.1°C) Member, openSUSE Heroes. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] any hints for getting ds1820s to work with my nano pi neo air?
I measure temperature with DS1820 hooked up to microcontrollers (PIC) or via serial interface to regular PCs, now I was hoping to use a nanopi neo air, but I am not getting anywhere. I have the modules loaded - w1-therm, wire, w1-gpio - but no devices turn up in /sys/bus/w1/devices. I'm connecting the DS1820s to GPIO11 - I guess I need to modify the DTB to make this work? -- Per Jessen, Zürich (8.5°C) Member, openSUSE Heroes. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] pxe
Thierry Reijnhout wrote: > hay opensuse arm team/mailing list > > i have 3 raspberry pi's 1 b and 2 b+. i am running rasbian on 2 of > those true pxe nfs boot without sd card... i woud love to run the 3e > one on opensuse. i now there is now out of the box solution and for > now i diddent find a way to get it gowing. starting kernel and then > the divice hangs is how far i got. so my quistion is how can i help > and how far are we whit pxe arm opensuse... and a more importend > cuastion is how and where can i join in to help/test etc I have Leap 15.0 running on my Raspi 3B+. I think I just used the lxqt jeos image. -- Per Jessen, Zürich (23.2°C) -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Problem with yast bootloader Paspi3B+
Eric Schirra wrote: > Hello, > > i have a problem with Bootloader in Yast under xfce. > I have not change the Bootloader itself. > It is grub2. > > I only click okay and then it rise up an error at step three > "configuration save": > > Details: unsupported combination of architecture aarch64 and disabled > EFI > Caller: /usr/share/YaST2/lib/bootloader/grub_install.rb:98 in 'target' FWIW, I think I saw the same problem only a few weeks ago. I hadn't changed any of the settings, but I wanted to use YaST to edit some kernel parameters (I'm not very literate with grub myself). It got completely screwed up so I just started from scratch. I think it is easily reproduced. -- Per Jessen, Zürich (9.2°C) http://www.jessen.ch/electricity - a nano pi smartmeter with openSUSE -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] vcio, STRICT_DEVMEM
Matthias Brugger wrote: > > > On 12/03/2019 09:04, Guillaume Gardet wrote: >> Hi Per, >> >>> -Original Message- >>> From: Per Jessen >>> Sent: 12 March 2019 08:58 >>> To: opensuse-arm@opensuse.org >>> Subject: Re: [opensuse-arm] vcio, STRICT_DEVMEM >>> >>> Per Jessen wrote: >>> >>>> Matthias Brugger wrote: >>>> >>>>> On 10/03/2019 19:35, Per Jessen wrote: >>>>>> Well, at least I have a vcio module that builds now, we'll see it >>>>>> if it also works. >>>>>> >>>>> >>>>> It seems that there is another thread on this mailing list, but I >>>>> wasn't able to find it. What do you want to achieve? >>>> >>>> Hi Matthias, >>>> >>>> nothing too complex I hope, I just want to control a series of >>>> WS2812 LEDs, using the code/utilities from >>>> >>>> https://github.com/jgarff/rpi_ws281x >>> > > I had a look on that code and it looks like a hack to me. I can't really comment - of the couple of projects I looked at (related to ws2812), this looked the most complete/useful. >>> I built the vcio module, seems to work fine. Then I built the >>> kernel without STRICT_DEVMEM and I can now control a string of >>> WS2812 LEDs. >> >> Thanks for your feedback! >> The vcio module can probably be upstreamed, or at least packaged in >> OBS, I guess. >> > > I don't think this is the right approach for upstream. If we want to > control these leds, then we should write a kernel driver which uses > the mbox and not implement detection etc in user-space. > If you want to use a LED matrix, then I think this is a good candidate > for a tinydrm driver in the kernel. again, I can't really comment on what is right or good - so just my observations: getting the vcio module to work was no big deal, just required a bit of research - I think even a relative newbie would manage to get it to work. About STRICT_DEVMEM - had I been able to disable with a kernel argument, that would have been really nice. In 2008, Bernhard Walle @ suse also proposed a sysctl "dev.mem.restricted", but I guess that didn't go through. -- Per Jessen, Zürich (5.0°C) member, openSUSE Heroes. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] vcio, STRICT_DEVMEM
Per Jessen wrote: > Matthias Brugger wrote: > >> On 10/03/2019 19:35, Per Jessen wrote: >>> Well, at least I have a vcio module that builds now, we'll see it if >>> it also works. >>> >> >> It seems that there is another thread on this mailing list, but I >> wasn't able to find it. What do you want to achieve? > > Hi Matthias, > > nothing too complex I hope, I just want to control a series of WS2812 > LEDs, using the code/utilities from > > https://github.com/jgarff/rpi_ws281x Well, for what's worth - using the vcio code from here: http://www.macs.hw.ac.uk/~hwloidl/hackspace/linux/drivers/char/broadcom/vcio.c (I forget exactly where I found it, probably on github). I built the vcio module, seems to work fine. Then I built the kernel without STRICT_DEVMEM and I can now control a string of WS2812 LEDs. -- Per Jessen, Zürich (3.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] vcio, STRICT_DEVMEM
Matthias Brugger wrote: > On 10/03/2019 19:35, Per Jessen wrote: >> Well, at least I have a vcio module that builds now, we'll see it if >> it also works. >> > > It seems that there is another thread on this mailing list, but I > wasn't able to find it. What do you want to achieve? Hi Matthias, nothing too complex I hope, I just want to control a series of WS2812 LEDs, using the code/utilities from https://github.com/jgarff/rpi_ws281x >> The code for using the PWM to generate control signals for a line of >> WS2812Bs also uses /dev/mem to access the Raspi hardware - with the >> openSUSE kernel, this is blocked by CONFIG_STRICT_DEVMEM. I don't >> see >> any kernel argument or switch to disable that restriction. (I tried >> strict_devmem=0, didn't work). >> >> I'm rebuilding a kernel without CONFIG_STRICT_DEVMEM, but I can't >> help wondering if we shouldn't have a dedicated kernel optimized for >> use on the Raspi? Using kernel-default seems silly. >> > > In general you can provide patches against openSUSE kernel > configuaration if there is anything you think it should be > enabled/disabled. Cool, I might well make some suggestions. > STRICT_DEVMEM is a security feature so IMHO there should be a good > reason to disable it. From your email I understand that you want to > access PWM via /dev/mem. That looks wrong. The PWMs should be accessed > through the sysfs. Yes, I get the idea of /dev/mem, but I see lots of code for Raspis that is using /dev/mem ? None of what I have seen even mentions having to disable STRICT_DEVMEM. > Can you please give some more background on what you want to do and > how you try to achieve that? For controlling the WS2812, I need to transmit data at around 800kHz - with libgpiod, I was only able to generate a waveform of about 400kHz (on a gpio). I gave that up and then I stumbled on https://github.com/jgarff/rpi_ws281x which looks to be the right way to go. That code expects to use /dev/vcio for talking to the GPU mailbox as well as /dev/mem for working with the PWM. -- Per Jessen, Zürich (5.3°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] libgpiod on RasPi 3B+ apparently does not work
Simon Gleissner wrote: > Question: did anyone here succeeded in using libgpiod for setting > GPIOs in Tumbleweed yet? Only just last week I had libgpiod working on 3B+, but I was using Leap15. -- Per Jessen, Zürich (4.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] vcio, STRICT_DEVMEM
Well, at least I have a vcio module that builds now, we'll see it if it also works. The code for using the PWM to generate control signals for a line of WS2812Bs also uses /dev/mem to access the Raspi hardware - with the openSUSE kernel, this is blocked by CONFIG_STRICT_DEVMEM. I don't see any kernel argument or switch to disable that restriction. (I tried strict_devmem=0, didn't work). I'm rebuilding a kernel without CONFIG_STRICT_DEVMEM, but I can't help wondering if we shouldn't have a dedicated kernel optimized for use on the Raspi? Using kernel-default seems silly. -- Per Jessen, Zürich (11.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] /dev/vcio for accessing the raspi "mailbox" ?
Torsten Duwe wrote: On Fri, 08 Mar 2019 18:19:13 +0100 Per Jessen wrote: https://patchwork.kernel.org/patch/10836377/ for the broadcom. Thanks Torsten, I'll have a look. Ok, you have the driver and the DT node, as proven by the kernel message in your first mail, so forget my previous remarks. drivers/mailbox/mailbox.c creates an internal device, but I see no consumers besides rpi-firmware. As Guillaume has already noted, downstream had created a device node here, which is lacking upstream. It sounds like that's what I need to look at first. Do you have a platform device named "raspberrypi-hwmon"? Yup, got it: /sys/devices/platform/soc/soc:firmware/raspberrypi-hwmon /sys/bus/platform/devices/raspberrypi-hwmon /sys/bus/platform/drivers/raspberrypi-hwmon /sys/bus/platform/drivers/raspberrypi-hwmon/raspberrypi-hwmon /Per -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] /dev/vcio for accessing the raspi "mailbox" ?
Torsten Duwe wrote: > On Fri, 08 Mar 2019 17:11:21 +0100 > Per Jessen wrote: > >> Guillaume Gardet wrote: > >> > I think /dev/vcio is a downstream feature only. So, not available >> > on openSUSE kernel which uses upstream kernels. >> > >> >> Thanks Guillaume >> >> so, what do I need to do to talk to the raspi mailbox? I tried >> creating /dev/vcio myself (majornum 100), but I'm clearly missing > > That's definitely the wrong way. This can only work around a broken > driver that somehow does not trigger udev. I was wondering. Looking at the bcm2835-mailbox driver, I see no char device being registered - there is another vcio driver out there, but tere is clearly some overlap with bcm2835-mailbox. >> whatever it is that provides that interface. > > A similar patch set has been submitted for sunXi this week. Look > for code that looks like > > https://patchwork.kernel.org/patch/10836377/ > > for the broadcom. Thanks Torsten, I'll have a look. -- Per Jessen, Zürich (6.6°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
RE: [opensuse-arm] /dev/vcio for accessing the raspi "mailbox" ?
Guillaume Gardet wrote: > Hi, > > >> -Original Message----- >> From: Per Jessen >> Sent: 08 March 2019 14:57 >> To: opensuse-arm@opensuse.org >> Subject: [opensuse-arm] /dev/vcio for accessing the raspi "mailbox" ? >> >> On my raspi 3b+, I'm trying out some code for controlling WS2812 LEDs >> - >> >> https://github.com/jgarff/rpi_ws281x >> >> The code uses /dev/vcio for mailbox communications - I guess there is >> a module that provides this interface, but I can't find it. It looks >> like >> bcm2835_mailbox is the right one, and it is part of the kernel. I >> also see in dmesg: >> >> [9.267410] bcm2835-mbox 3f00b880.mailbox: mailbox enabled >> >> What am I missing? > > I think /dev/vcio is a downstream feature only. So, not available on > openSUSE kernel which uses upstream kernels. > Thanks Guillaume so, what do I need to do to talk to the raspi mailbox? I tried creating /dev/vcio myself (majornum 100), but I'm clearly missing whatever it is that provides that interface. -- Per Jessen, Zürich (7.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] /dev/vcio for accessing the raspi "mailbox" ?
On my raspi 3b+, I'm trying out some code for controlling WS2812 LEDs - https://github.com/jgarff/rpi_ws281x The code uses /dev/vcio for mailbox communications - I guess there is a module that provides this interface, but I can't find it. It looks like bcm2835_mailbox is the right one, and it is part of the kernel. I also see in dmesg: [9.267410] bcm2835-mbox 3f00b880.mailbox: mailbox enabled What am I missing? -- Per Jessen, Zürich (6.9°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 3 B+ ?
Per Jessen wrote: > I would like to repeat the exercise with the LXQT image, but I would > need to get the ethernet interface to run. 'ifup eth0' takes a while, > then reports 'setup-in-progress'. The following works: Starting with the LXQT image: http://download.opensuse.org/ports/aarch64/distribution/leap/15.0/appliances/openSUSE-Leap15.0-ARM-LXQT-raspberrypi3.aarch64-2018.07.02-Buildlp150.1.1.raw.xz After the first boot, I have a machine without network. I stop/disable NetworkManager and I can now make the wifi work. I then upgraded the kernel and rebooted - now I have ethernet and I can complete with a zypper patch. LXDE looks good, it's quite fast and responsive. With KDE, I also had sound working, that one I still have to work on. I think I saw a kernel oops. -- Per Jessen, Zürich (11.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 3 B+ ?
Per Jessen wrote: [snip] > - the wifi interface kept going up and down like a yoyo, > sometimes loosing the default route. It also kept changing the MAC > address, randomly: It looks like this is caused by NetworkManager. I don't understand why it is running though, wicked is in charge? Before I restarted just now, I saw NetworkManager logging messages about "set-hw-addr" ? Currently, after completing the zypper patch, and masking out NetworkManager, both interfaces are running, but I cannot log in to the GUI. I keep being thrown back to the login screen. I think something may well have gone wrong during the zypper patch ? I would like to repeat the exercise with the LXQT image, but I would need to get the ethernet interface to run. 'ifup eth0' takes a while, then reports 'setup-in-progress'. -- Per Jessen, Zürich (13.9°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 3 B+ ?
Per Jessen wrote: > Quick summary - > > with Leap15 from the image above, I have ethernet and wlan devices, > but I cannot activate them. I tried creating a plain user, but YaST > crashed, also when attempting to set date&time. > > Then I switched to Tumbleweed: > >http://download.opensuse.org/ports/aarch64/tumbleweed/images/openSUSE-Tumbleweed-ARM-KDE-raspberrypi3.aarch64-2019.02.12-Snapshot20190217.raw.xz > > With that, I have ethernet, but no wifi, not even a wlan device. I > see my Logitech trackball recognised in dmesg output, but sddm-greeter > is spinning using up 250% CPU. Over the weekend I switched back to Leap15, but using the LQXT image. KDE just seemed a little too "heavy" for the Raspi. LQXT seems quite snappy, and although the ethernet interface still isn't running, I managed to get the wifi up. Last night, I started a "zypper patch" which wanted to update/install some 658 packages. This was a bit of a pain - the wifi interface kept going up and down like a yoyo, sometimes loosing the default route. It also kept changing the MAC address, randomly: Mar 3 21:32:24 dresden dhcpd: DHCPACK on 192.168.7.56 to 0a:13:0b:2c:96:be via eth0 Mar 3 21:37:35 dresden dhcpd: DHCPACK on 192.168.7.56 to 9a:7a:64:00:22:de via eth0 Mar 3 21:42:55 dresden dhcpd: DHCPACK on 192.168.7.56 to fe:e5:18:7f:ca:43 via eth0 Mar 3 21:48:13 dresden dhcpd: DHCPACK on 192.168.7.56 to 0a:dd:4c:96:00:c1 via eth0 Mar 3 21:53:23 dresden dhcpd: DHCPACK on 192.168.7.56 to 22:6d:fd:e2:dd:82 via eth0 Mar 3 21:58:43 dresden dhcpd: DHCPACK on 192.168.7.56 to 82:32:ac:ce:ec:bc via eth0 Mar 3 22:03:57 dresden dhcpd: DHCPACK on 192.168.7.56 to 02:fc:a1:cc:d3:60 via eth0 Mar 3 22:14:28 dresden dhcpd: DHCPACK on 192.168.7.56 to da:ab:ac:bd:a1:4b via eth0 Mar 3 22:19:44 dresden dhcpd: DHCPACK on 192.168.7.56 to 3a:58:9f:d1:0b:15 via eth0 Mar 3 22:25:01 dresden dhcpd: DHCPACK on 192.168.7.56 to 7a:c0:b5:e0:f7:2a via eth0 Mar 3 22:30:16 dresden dhcpd: DHCPACK on 192.168.7.56 to 2e:e0:8c:b7:c5:15 via eth0 Mar 3 22:35:32 dresden dhcpd: DHCPACK on 192.168.7.56 to aa:95:18:c2:e9:03 via eth0 Mar 3 22:40:52 dresden dhcpd: DHCPACK on 192.168.7.56 to 4a:81:74:76:4c:97 via eth0 Mar 3 22:51:20 dresden dhcpd: DHCPACK on 192.168.7.56 to 8e:19:2e:37:40:14 via eth0 Mar 3 22:56:36 dresden dhcpd: DHCPACK on 192.168.7.56 to 7a:d7:4a:e1:79:0d via eth0 Mar 3 23:01:57 dresden dhcpd: DHCPACK on 192.168.7.56 to a2:60:72:98:19:a4 via eth0 Mar 3 23:07:09 dresden dhcpd: DHCPACK on 192.168.7.56 to c2:d9:36:93:ee:85 via eth0 Mar 3 23:12:25 dresden dhcpd: DHCPACK on 192.168.7.56 to 82:ee:e6:b7:d0:90 via eth0 Mar 3 23:20:16 dresden dhcpd: DHCPACK on 192.168.7.56 to 72:28:67:3b:6f:ad via eth0 Mar 3 23:22:58 dresden dhcpd: DHCPACK on 192.168.7.56 to da:41:ef:48:ab:b7 via eth0 Mar 3 23:33:31 dresden dhcpd: DHCPACK on 192.168.7.56 to 1a:94:2d:c0:31:55 via eth0 Mar 3 23:38:45 dresden dhcpd: DHCPACK on 192.168.7.56 to 7a:ed:de:be:a7:10 via eth0 Mar 3 23:49:18 dresden dhcpd: DHCPACK on 192.168.7.56 to 56:61:be:83:df:e0 via eth0 Mar 3 23:54:34 dresden dhcpd: DHCPACK on 192.168.7.56 to 56:ba:50:1b:35:19 via eth0 Mar 3 23:59:49 dresden dhcpd: DHCPACK on 192.168.7.56 to fe:0a:70:5a:a9:56 via eth0 Mar 4 00:05:16 dresden dhcpd: DHCPACK on 192.168.7.56 to 72:84:b1:e1:90:33 via eth0 Mar 4 00:10:21 dresden dhcpd: DHCPACK on 192.168.7.56 to 16:9e:7e:4a:3c:d1 via eth0 Mar 4 00:15:37 dresden dhcpd: DHCPACK on 192.168.7.56 to 72:6d:1d:af:3b:95 via eth0 Mar 4 00:20:54 dresden dhcpd: DHCPACK on 192.168.7.56 to de:73:4f:ee:12:13 via eth0 Mar 4 00:26:10 dresden dhcpd: DHCPACK on 192.168.7.56 to 3a:5b:3f:fb:55:e8 via eth0 Mar 4 00:31:25 dresden dhcpd: DHCPACK on 192.168.7.56 to ee:a6:74:8e:76:fd via eth0 Mar 4 00:36:41 dresden dhcpd: DHCPACK on 192.168.7.56 to 32:52:1a:25:1e:f7 via eth0 Mar 4 00:41:58 dresden dhcpd: DHCPACK on 192.168.7.56 to ee:3c:98:b9:8e:7f via eth0 Mar 4 00:47:13 dresden dhcpd: DHCPACK on 192.168.7.56 to 82:f6:a1:89:e7:8d via eth0 Mar 4 00:52:29 dresden dhcpd: DHCPACK on 192.168.7.56 to 1a:c3:36:6c:63:8b via eth0 This morning after finishing the download, I restarted 'zypper patch', which is almost done now, only 30 packages left :-) -- Per Jessen, Zürich (13.5°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 3 B+ ?
Torsten Duwe wrote: > On Fri, Mar 01, 2019 at 01:59:36PM +0100, Per Jessen wrote: >> I have just acquired two of these, one for my son's school project, >> one for our mediacentre. Using the KDE appliance, it boots up fine, >> but as soon as I start setting up the wifi, it crashes. Then I tried >> usig yast to set date&time - crash. > > Are they equipped with _appropriate_ power supplies? RPi3 is said to > have higher demands than just an ordinary 5V/2.5A plugger. Ah, I was not aware. Well, the power supply says 5V/3400mA, it has multiple usb sockets at max 2400/socket, Looking at the power supply supplied by e.g. Conrad, they are also 2500mA. > Some shops sell 3.0 amps minimum, others swear by raising Vout to > 5.2V. My assumption is those rascals like to demand sudden current > bursts, e.g. when certain peripherials kick in or the CPU gets to do > some work. That is possible, but sofar I'm still installing :-) Also, when I tried with TW a little later, it worked fairly well, at least it didn't crash. > For the media centre you might want to look at libreELEC, for a > comparison, just to see whether that runs stable. OTOH it's only > 32-bits wide :-P https://libreelec.tv/downloads_new/raspberry-pi-3-3/ Thanks, I'll check it out. -- Per Jessen, Zürich (6.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 3 B+ ?
Stefan Seyfried wrote: > Am 01.03.19 um 14:53 schrieb Torsten Duwe: >> For the media centre you might want to look at libreELEC, for a >> comparison, just to see whether that runs stable. OTOH it's only >> 32-bits wide :-P https://libreelec.tv/downloads_new/raspberry-pi-3-3/ > > Or just plain raspbian, does multimedia very well out of the box. Okay, I'll check those out too. The key thing is getting it to run MythTV. > BTW: what is the benefit of a 64bit system on a 1GB RAM machine? > Apart from breaking most of the multimedia stuff and being dog slow > compared to raspbian? I did think it seemed a bit slow, when compared to running Leap15 on my NanoPis. Is that likely? -- Per Jessen, Zürich (8.0°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 3 B+ ?
Per Jessen wrote: > Axel Braun wrote: > >> Am Freitag, 1. März 2019, 13:59:36 CET schrieb Per Jessen: >>> I have just acquired two of these, one for my son's school project, >>> one >>> for our mediacentre. Using the KDE appliance, it boots up fine, but >>> as >>> soon as I start setting up the wifi, it crashes. Then I tried usig >>> yast to set date&time - crash. >> >> What image did you use? > > Sorry, I did mean to add that, - > > http://download.opensuse.org/ports/aarch64/distribution/leap/15.0/appliances/openSUSE-Leap15.0-ARM-KDE-raspberrypi3.aarch64-2018.07.02-Buildlp150.1.1.raw.xz > > I've just now switched to trying out TW instead. I'll let you know > how that goes. > I should also mention I'm not using KDE sofar, only the shell. Quick summary - with Leap15 from the image above, I have ethernet and wlan devices, but I cannot activate them. I tried creating a plain user, but YaST crashed, also when attempting to set date&time. Then I switched to Tumbleweed: http://download.opensuse.org/ports/aarch64/tumbleweed/images/openSUSE-Tumbleweed-ARM-KDE-raspberrypi3.aarch64-2019.02.12-Snapshot20190217.raw.xz With that, I have ethernet, but no wifi, not even a wlan device. I see my Logitech trackball recognised in dmesg output, but sddm-greeter is spinning using up 250% CPU. -- Per Jessen, Zürich (8.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 3 B+ ?
Alexander Bergmann wrote: Hi Per, which openSUSE version are you running on your Pi? I would try to test WiFi with just the command line interface, to make sure it has nothing to do with KDE. If you can track it down to KDE then some error message/debug information would be helpfull. Always feel free to open a bug report about it with as much information as possible, so it can be tracked down properly. Thanks Alex - I think I might just do that. I started using the Leap15 KDE applicance, now I have switched to TW, I now have working ethernet, but instead the wifi doesn't show up. Instead, changing date&time with Yast worked fine :-) /Per -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 3 B+ ?
Axel Braun wrote: > Am Freitag, 1. März 2019, 13:59:36 CET schrieb Per Jessen: >> I have just acquired two of these, one for my son's school project, >> one >> for our mediacentre. Using the KDE appliance, it boots up fine, but >> as >> soon as I start setting up the wifi, it crashes. Then I tried usig >> yast to set date&time - crash. > > What image did you use? Sorry, I did mean to add that, - http://download.opensuse.org/ports/aarch64/distribution/leap/15.0/appliances/openSUSE-Leap15.0-ARM-KDE-raspberrypi3.aarch64-2018.07.02-Buildlp150.1.1.raw.xz I've just now switched to trying out TW instead. I'll let you know how that goes. I should also mention I'm not using KDE sofar, only the shell. -- Per Jessen, Zürich (8.7°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] Raspberry Pi 3 B+ ?
I have just acquired two of these, one for my son's school project, one for our mediacentre. Using the KDE appliance, it boots up fine, but as soon as I start setting up the wifi, it crashes. Then I tried usig yast to set date&time - crash. -- Per Jessen, Zürich (7.5°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] nanopi neo air - updated u-boot to the most recent from friendlyarm
The latest u-boot from friendlyarm still doesn't appear to support efi boot - the openSUSE TW Jeos does not boot. Personally I'm happy with using the leap15 applicance for nanopi neo (without air), and updating the dtb and the firmware so I can get wifi. Should I update our wiki and make people aware the current setup won't actually work, as described? FriendlyARM provides their "eflasher" utility, which is just a custom Ubuntu system with a script/binary for flashing the eMMC. I just don't see where I would put my own (newer) u-boot in. -- Per Jessen, Zürich (-0.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] nanopi neo - blue led ?
Andreas Schwab wrote: On Jan 28 2019, Per Jessen wrote: The interface name change is due to an updated dtb, but where do the changed options come from? Specifically, what happened to the 'heartbeat' option? Is the ledtrig-heartbeat module loaded? Thanks, it wasn't. I did not occur to me it might be provided by a module. /Per -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] nanopi neo - blue led ?
I was hoping to make the blue led flash in "heartbeat" mode. With the
on-flash Ubuntu 15.10, kernel 3.4.39, the interface looks like this:
# cat /sys/class/leds/blue_led/trigger
none mmc0 mmc1 mmc2 timer [heartbeat] backlight gpio default-on rfkill0
rfkill1 rfkill2
With Leap15 kernel 4.12.14:
# cat /sys/class/leds/nanopi:blue:status/trigger
[none] kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock
kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock
kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock usb-gadget usb-host
disk-activity ide-disk mtd nand-disk cpu cpu0 cpu1 cpu2 cpu3 panic mmc0
mmc1 rfkill-any rfkill0
The interface name change is due to an updated dtb, but where do the
changed options come from? Specifically, what happened to
the 'heartbeat' option? It looks it can be emulated by the timer
trigger, and the /sys/class/leds//delay_{on,off} values, but
neither seems to be available on the nanopi neo air?
(hardly a critical issue, I'm just curious).
--
Per Jessen, Zürich (2.4°C)
http://www.dns24.ch/ - your free DNS host, made in Switzerland.
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] trying out Jeos for nanopi neo air
Andreas Fc3a4rber wrote: > Am 27.01.19 um 14:57 schrieb Per Jessen: >> Andreas Fc3a4rber wrote: >> >>> Am 26.01.19 um 23:15 schrieb Per Jessen: >>>> Per Jessen wrote: >>>> >>>>> I've just booted a nanopi neo air with >>>> >> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/NanoPiNeo/images/openSUSE-Tumbleweed-ARM-JeOS-nanopineoair.armv7l-2019.01.08-Build6.14.raw.xz >>>>> >>>>> and I am greeted with: >>>>> >>>>> Ubuntu 15.10 FriendlyARM ttyS0 >>>>> FriendlyARM login: >>>>> >>>>> ??? > [...] >>> It sounds to me as if it's booting from eMMC and doesn't support >>> UEFI yet. >> >> Afaict, it's simply because the image above does not have the >> boot.scr. > > After checking for boot.scr it should check for efi/boot/bootarm.efi. > So as I said, if it doesn't do that, your U-Boot is too old or > misconfigured and needs to be replaced. Okay, that makes sense. > Our image surely does not contain Ubuntu, so that must be coming from > somewhere other than our image! Yes, this seems to be what FriendlyARM supplies by default. I've made quite a bit of progress now, Leap15 is running from SD. I almost have wireless working, just now getting crda and wireless-regdb installed. -- Per Jessen, Zürich (4.7°C) member, openSUSE heroes. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] trying out Jeos for nanopi neo air
Andreas Fc3a4rber wrote: > Am 26.01.19 um 23:15 schrieb Per Jessen: >> Per Jessen wrote: >> >>> I've just booted a nanopi neo air with >>> >>> >> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/NanoPiNeo/images/openSUSE-Tumbleweed-ARM-JeOS-nanopineoair.armv7l-2019.01.08-Build6.14.raw.xz >>> >>> and I am greeted with: >>> >>> Ubuntu 15.10 FriendlyARM ttyS0 >>> FriendlyARM login: >>> >>> ??? >> >> Having also tried with nanopineo Leap15 from ports (which worked >> fine), it appears the problem is in in the lack of a boot.scr file >> (in the above). > > As a reminder, I prepared that image about two years ago, and this is > the first real test feedback we're getting - that's why it's not in > Factory:ARM:Live but in Contrib:NanoPiNeo. So you'll need to > investigate any problems at your own, as no one else here seems to > have that board. I've had two for about two years, when I started with them, I had to do most of the work by hand :-) I'm repeating it now because the SD card started failing. > It sounds to me as if it's booting from eMMC and doesn't support UEFI > yet. Afaict, it's simply because the image above does not have the boot.scr. Today I switched to using the leap15 nanopineo appliance from ports/ - http://download.opensuse.org/ports/armv7hl/distribution/leap/15.0/appliances/ That's working a lot better, but I'm having trouble getting the wifi to work. > Then instead of adding an older boot method to our image, you > should upgrade your U-Boot on eMMC - extract the > /boot/u-boot-sunxi-with-spl.bin from our rpm u-boot-nanopineoair and > dd it to its expected location of seek=8k on the eMMC's mmcblkX - > compare other boards' HCL Wiki pages, e.g., Pine64. > Depending on how the Neo Air's boot flow is, erasing U-Boot on eMMC > might also make it fall back to SD, but having it on SPI or eMMC would > seem preferable, as you can then have a "normal" GPT on SD. Thanks, I'll check this out. -- Per Jessen, Zürich (4.4°C) member, openSUSE Heroes -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] trying out Jeos for nanopi neo air
Per Jessen wrote: > I've just booted a nanopi neo air with > > http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/NanoPiNeo/images/openSUSE-Tumbleweed-ARM-JeOS-nanopineoair.armv7l-2019.01.08-Build6.14.raw.xz > > and I am greeted with: > > Ubuntu 15.10 FriendlyARM ttyS0 > FriendlyARM login: > > ??? Having also tried with nanopineo Leap15 from ports (which worked fine), it appears the problem is in in the lack of a boot.scr file (in the above). -- Per Jessen, Zürich (3.8°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] trying out Jeos for nanopi neo air
I've just booted a nanopi neo air with http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/NanoPiNeo/images/openSUSE-Tumbleweed-ARM-JeOS-nanopineoair.armv7l-2019.01.08-Build6.14.raw.xz and I am greeted with: Ubuntu 15.10 FriendlyARM ttyS0 FriendlyARM login: ??? The default login as per https://en.opensuse.org/HCL:NanoPi_Neo_Air doesn't work either. -- Per Jessen, Zürich (3.1°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] CPU frequency / temperature management for NanoPi NEO
opsyzone wrote: > Hi, > > I tried to rsync some Gigabytes of files to my NanoPi NEO and suddenly > it stopped working: It had run really hot. > Do we have some kind of CPU heat- or frequency-control available? A heatsink? :-) Cut a 10x10mm bit of an old heatsink and stick it on, that'll do the trick. At leats on my two nano pi neo air. -- Per Jessen, Zürich (26.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] nanopi neo air ?
Andreas Färber wrote: Hi Per, Am 18.04.2017 um 18:51 schrieb Andreas Färber: With today's update to v2017.05-rc2, there now is a u-boot-nanopineoair package in Base:System:Staging for you to test. If you interrupt it on serial and type "printenv fdtfile", I would expect that you see a different .dtb filename than for -nanopineo. The sun8i-h3-nanopi-neo-air.dtb file is however not part of kernel 4.11 (i.e., not in Kernel:HEAD), so you would need to try kernel-vanilla and dtb-sun8i from Kernel:linux-next. Or try just the .dtb file from there, with a Factory or Kernel:HEAD kernel-lpae. To use the partially-working sun8i-h3-nanopi-neo.dtb as before with the new u-boot-nanopineoair, you could use a symlink. Small steps... Haven't heard back here yet. Note that I've recently (when touching it) prepared a JeOS image with the above bootloader: https://en.opensuse.org/HCL:NanoPi_Neo_Air It still requires the above workarounds for the .dtb, thus in a Contrib. Some feedback before oSC17 would be appreciated, as I don't have one. Hi Andreas I have a working system, it's been running for a while measuring electricity consumption. https://www.jessen.ch/electricity I am currently missing two things - I want to boot from the built-in eMMC flash and I would prefer to run a clean Leap422. The latter isn't so important though. I started with your TW JeOS image for the nanopi neo: openSUSE-Tumbleweed-ARM-JeOS-nanopineo.armv7l-2017.01.17-Build5.2.raw.xz I updated the dtb with some patches from a Dutch guy, I rebuilt the kernel, got new firmware and nvram for the wifi. It was a great learning exercise. Gruss Per -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] ntp, a couple of minor issues
Stefan Bruens wrote: > On Mittwoch, 22. März 2017 08:43:43 CET Per Jessen wrote: >> Alexander Graf wrote: >> > On 20/03/2017 16:11, Eric Curtin wrote: >> >> Yeah "iburst" was all that this needed. It's perfect for my needs >> >> at least. Haven't seen anything like that in my dracut scripts >> >> either. Similar to Per, I may not be looking for the right thing. >> > >> > I can't find it anymore either. Odd. >> > >> > So historically we used to have a hack that set the system time to >> > the >> > >> > initrd build time if it was bogus: >> >https://github.com/openSUSE/mkinitrd/blob/ad190ad24a9f3881afa11c47aecc8625b >> >286d0d4/scripts/boot-start.sh#L210> >> > That got removed with the transition to dracut and I seem to >> > remember that the hack we then added was to take the last mounted >> > time from your / file system and apply that as system time. But I >> > agree that I can't find any reference to it. >> > >> > I'm surprised any of the non-RTC ARM systems boot at all then - >> > ext3 used to complain really loudly if the last mount time was >> > newer than the system time. >> >> I've just had to reboot my nanopi, it came up with "2017-01-10 >> 11:53:57". In dmesg, the built-in rtc reports >> >> [6.965339] sun6i-rtc 1f0.rtc: setting system clock to >> [1970-01-01 >> 00:00:13 UTC (13) >> >> Looking at the root file system: >> >> # tune2fs -l /dev/mmcblk0p2 >> tune2fs 1.43.3 (04-Sep-2016) >> Filesystem volume name: ROOT >> Last mounted on: / >> [snip] >> Filesystem created: Thu Jan 19 04:00:24 2017 >> Last mount time: Tue Jan 10 11:54:03 2017 >> Last write time: Tue Jan 10 11:53:59 2017 >> Mount count: 57 >> Maximum mount count: -1 >> Last checked: Tue Mar 7 21:59:21 2017 >> >> So, something did set the time? I mean, that timestamp from >> 2017/01/10 must come from somewhere? > > If you only reboot, i.e. keep the power supply connected, the RTC does > its job. It is not battery backed, but still an RTC. Ah, of course. However, I've just repeated the experiment - power off and reboot, and it comes back up with a timestamp in January 2017: ssh root@nano1 Password: Last login: Wed Mar 22 09:40:28 2017 from 2001:db8:4c68:1:21d:92ff:fe39:a132 Have a lot of fun... nano1:~ # date Tue 10 Jan 11:55:33 CET 2017 -- Per Jessen, Zürich (7.0°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] ntp, a couple of minor issues
Alexander Graf wrote: > > > On 20/03/2017 16:11, Eric Curtin wrote: >> Yeah "iburst" was all that this needed. It's perfect for my needs at >> least. Haven't seen anything like that in my dracut scripts either. >> Similar to Per, I may not be looking for the right thing. > > I can't find it anymore either. Odd. > > So historically we used to have a hack that set the system time to the > initrd build time if it was bogus: > >https://github.com/openSUSE/mkinitrd/blob/ad190ad24a9f3881afa11c47aecc8625b286d0d4/scripts/boot-start.sh#L210 > > That got removed with the transition to dracut and I seem to remember > that the hack we then added was to take the last mounted time from > your / file system and apply that as system time. But I agree that I > can't find any reference to it. > > I'm surprised any of the non-RTC ARM systems boot at all then - ext3 > used to complain really loudly if the last mount time was newer than > the system time. I've just had to reboot my nanopi, it came up with "2017-01-10 11:53:57". In dmesg, the built-in rtc reports [6.965339] sun6i-rtc 1f0.rtc: setting system clock to 1970-01-01 00:00:13 UTC (13) Looking at the root file system: # tune2fs -l /dev/mmcblk0p2 tune2fs 1.43.3 (04-Sep-2016) Filesystem volume name: ROOT Last mounted on: / [snip] Filesystem created: Thu Jan 19 04:00:24 2017 Last mount time: Tue Jan 10 11:54:03 2017 Last write time: Tue Jan 10 11:53:59 2017 Mount count: 57 Maximum mount count: -1 Last checked: Tue Mar 7 21:59:21 2017 So, something did set the time? I mean, that timestamp from 2017/01/10 must come from somewhere? -- Per Jessen, Zürich (5.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] ntp, a couple of minor issues
Alexander Graf wrote: > > > On 21/03/2017 09:52, Per Jessen wrote: >> Alexander Graf wrote: >> >>> >>> >>> On 20/03/2017 16:11, Eric Curtin wrote: >>>> Yeah "iburst" was all that this needed. It's perfect for my needs >>>> at least. Haven't seen anything like that in my dracut scripts >>>> either. Similar to Per, I may not be looking for the right thing. >>> >>> I can't find it anymore either. Odd. >>> >>> So historically we used to have a hack that set the system time to >>> the initrd build time if it was bogus: >>> >>> https://github.com/openSUSE/mkinitrd/blob/ad190ad24a9f3881afa11c47aecc8625b286d0d4/scripts/boot-start.sh#L210 >>> >>> That got removed with the transition to dracut and I seem to >>> remember that the hack we then added was to take the last mounted >>> time from your / file system and apply that as system time. But I >>> agree that I can't find any reference to it. >> >> Sounds like a pretty good idea. >> >>> I'm surprised any of the non-RTC ARM systems boot at all then - ext3 >>> used to complain really loudly if the last mount time was newer than >>> the system time. >> >> AFAICT, my nanopi neo air does have an RTC, but it still comes up >> with clock set to 1970 on boot. > > There's a separate RTC module on sale as far as I can tell, but > nothing built in. I think I saw that too, but then I noticed these messages : # dmesg | grep rtc [6.850912] sun6i-rtc 1f0.rtc: rtc core: registered rtc-sun6i as rtc0 [6.850920] sun6i-rtc 1f0.rtc: RTC enabled [6.960530] sun6i-rtc 1f0.rtc: setting system clock to 1970-01-01 00:00:13 UTC (13) > You can usually tell quite easily whether you have a working RTC by > searching for a battery on the board. No battery means no working RTC, > as there's nothing that would preserve the time while it's not plugged > in. There is definitely no battery, not enough room :-) -- Per Jessen, Zürich (12.0°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] ntp, a couple of minor issues
Alexander Graf wrote: > > > On 20/03/2017 16:11, Eric Curtin wrote: >> Yeah "iburst" was all that this needed. It's perfect for my needs at >> least. Haven't seen anything like that in my dracut scripts either. >> Similar to Per, I may not be looking for the right thing. > > I can't find it anymore either. Odd. > > So historically we used to have a hack that set the system time to the > initrd build time if it was bogus: > >https://github.com/openSUSE/mkinitrd/blob/ad190ad24a9f3881afa11c47aecc8625b286d0d4/scripts/boot-start.sh#L210 > > That got removed with the transition to dracut and I seem to remember > that the hack we then added was to take the last mounted time from > your / file system and apply that as system time. But I agree that I > can't find any reference to it. Sounds like a pretty good idea. > I'm surprised any of the non-RTC ARM systems boot at all then - ext3 > used to complain really loudly if the last mount time was newer than > the system time. AFAICT, my nanopi neo air does have an RTC, but it still comes up with clock set to 1970 on boot. -- Per Jessen, Zürich (11.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] ntp, a couple of minor issues
Alexander Graf wrote: > The way this usually gets handled in openSUSE is by reading the > unmount time of your root file system. There should be a script in > dracut that finds out when your rootfs was last unmounted and sets the > system time to that if the system time is bogus. > > I'm not quite sure why that doesn't kick in for you. Maybe it only > works on ext4? I looked through the dracut scripts (usr/lib/dracut), I can't find anything like that. Maybe I'm not looking for the right thing. -- Per Jessen, Zürich (17.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] ntp, a couple of minor issues
Eric Curtin wrote: > Hi Guys, > > On the rpi3 since it does not seem to have any CMOS battery type thing > (correct me if I'm wrong), it boots with the epoch time on boot every > time. Same on my nanopi neo air. > I have added an internal corporate ntp server to /etc/ntp.conf, which > works fine, but it takes quite a while for the ntp daemon to sync the > time. The time needs to be correct as some things I am using on the > rpi3 depend on the time being correct (such as docker). Generally > about four minutes in, the time successfully changes: > > Thu Jan 1 01:03:50 IST 1970 > Thu Mar 16 11:45:19 GMT 2017 > > I am connected via ethernet, I see the daemon is configured in systemd > to start after network.target, but it seems this is not enough (maybe > it's too soon to start the ntp daemon?) to get the time synced > quickly. The ntp start up script includes a '-g' option to allow big jumps (clearly needed). How much delay do you see between the network coming up and time being set? > Also when this time jump occurs, XFCE decides to lock my screen, so I > have to login again. > > Any ideas on solutions, before I come up with my own? What is the real problem - that it takes too long before time is set? That might suggest that ntpd is having trouble talking to the time server. Maybe DNS delays? -- Per Jessen, Zürich (12.2°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] NTP on nanopi neo (air) ?
Brüns, Stefan wrote: > On Mittwoch, 15. März 2017 08:52:28 CET Per Jessen wrote: >> I don't seem to be able to run NTP on my nanopi neo air - when I try >> to start it, it enters a loop of stopping and starting, reporting >> "0.0.0.0 c01d 0d kern kernel time sync disabled". > > Are you sure this is the complete message? Please post the complete > message,including the timestamps and linebreaks, as you did for the > dmesg output. Sorry, no, that wasn't the complete log. This is the bit that repeats when ntpd is being restarted: 15 Mar 19:55:39 ntpd[6275]: 192.168.2.254 local addr 192.168.2.40 -> 15 Mar 19:55:39 ntp_intres[6276]: 0.0.0.0 c01d 0d kern kernel time sync disabled 15 Mar 19:55:39 ntpd[6275]: 0.0.0.0 c01d 0d kern kernel time sync disabled 15 Mar 19:55:40 ntpd[6292]: Listen and drop on 0 v6wildcard [::]:123 15 Mar 19:55:40 ntpd[6292]: Listen and drop on 1 v4wildcard 0.0.0.0:123 15 Mar 19:55:40 ntpd[6292]: Listen normally on 2 lo 127.0.0.1:123 15 Mar 19:55:40 ntpd[6292]: Listen normally on 3 wlan0 192.168.2.40:123 15 Mar 19:55:40 ntpd[6292]: Listen normally on 4 lo [::1]:123 15 Mar 19:55:40 ntpd[6292]: Listen normally on 5 wlan0 [2a03:7520:4c68:1:ff99::bf4f]:123 15 Mar 19:55:40 ntpd[6292]: Listen normally on 6 wlan0 [2a03:7520:4c68:1:890f:3340:d181:8f2e]:123 15 Mar 19:55:40 ntpd[6292]: Listen normally on 7 wlan0 [2a03:7520:4c68:1:96a1:a2ff:fea3:ba7a]:123 15 Mar 19:55:40 ntpd[6292]: Listen normally on 8 wlan0 [fe80::96a1:a2ff:fea3:ba7a%2]:123 15 Mar 19:55:40 ntpd[6292]: Listening on routing socket on fd #25 for interface updates 15 Mar 19:55:40 ntpd[6292]: Listen normally on 9 multicast [ff05::101]:123 15 Mar 19:55:40 ntpd[6292]: Joined ff05::101 socket to multicast group ff05::101 15 Mar 19:55:40 ntpd[6292]: 0.0.0.0 c01d 0d kern kernel time sync enabled 15 Mar 19:55:40 ntpd[6292]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM 15 Mar 19:55:40 ntpd[6292]: 0.0.0.0 c016 06 restart 15 Mar 19:55:41 ntpd[6292]: Listen for broadcasts to 192.168.7.255 on interface #3 wlan0 15 Mar 19:55:42 ntpd[6292]: ::1 config: server 192.168.2.254 15 Mar 19:55:42 ntpd[6292]: ntpd exiting on signal 15 (Terminated) 15 Mar 19:55:42 ntpd[6292]: 192.168.2.254 local addr 192.168.2.40 -> 15 Mar 19:55:42 ntpd[6292]: 0.0.0.0 c01d 0d kern kernel time sync disabled 15 Mar 19:55:42 ntp_intres[6293]: 0.0.0.0 c01d 0d kern kernel time sync disabled > Read https://www.novell.com/coolsolutions/feature/15345.html and try > if this helps ... Nope - I added "server 192.168.2.254 burst iburst", almost the same result as above. Interesting - then I ran "strace ntpd -u ntp:ntp -c /etc/ntp.conf", and that worked. At least it keeps running: 15 Mar 19:59:28 ntpd[8033]: ntpd exiting on signal 15 (Terminated) 15 Mar 19:59:28 ntpd[8033]: 192.168.2.254 local addr 192.168.2.40 -> 15 Mar 19:59:28 ntpd[8033]: 0.0.0.0 c01d 0d kern kernel time sync disabled 15 Mar 19:59:28 ntp_intres[8034]: 0.0.0.0 c01d 0d kern kernel time sync disabled 15 Mar 20:01:26 ntpd[8263]: Listen and drop on 0 v6wildcard [::]:123 15 Mar 20:01:26 ntpd[8263]: Listen and drop on 1 v4wildcard 0.0.0.0:123 15 Mar 20:01:26 ntpd[8263]: Listen normally on 2 lo 127.0.0.1:123 15 Mar 20:01:26 ntpd[8263]: Listen normally on 3 wlan0 192.168.2.40:123 15 Mar 20:01:26 ntpd[8263]: Listen normally on 4 lo [::1]:123 15 Mar 20:01:26 ntpd[8263]: Listen normally on 5 wlan0 [2a03:7520:4c68:1:ff99::bf4f]:123 15 Mar 20:01:26 ntpd[8263]: Listen normally on 6 wlan0 [2a03:7520:4c68:1:890f:3340:d181:8f2e]:123 15 Mar 20:01:26 ntpd[8263]: Listen normally on 7 wlan0 [2a03:7520:4c68:1:96a1:a2ff:fea3:ba7a]:123 15 Mar 20:01:26 ntpd[8263]: Listen normally on 8 wlan0 [fe80::96a1:a2ff:fea3:ba7a%2]:123 15 Mar 20:01:26 ntpd[8263]: Listening on routing socket on fd #25 for interface updates 15 Mar 20:01:26 ntpd[8263]: Listen normally on 9 multicast [ff05::101]:123 15 Mar 20:01:26 ntpd[8263]: Joined ff05::101 socket to multicast group ff05::101 15 Mar 20:01:26 ntpd[8263]: 0.0.0.0 c01d 0d kern kernel time sync enabled 15 Mar 20:01:26 ntpd[8263]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM 15 Mar 20:01:26 ntpd[8263]: 0.0.0.0 c016 06 restart 15 Mar 20:01:27 ntpd[8263]: Listen for broadcasts to 192.168.7.255 on interface #3 wlan0 15 Mar 20:01:48 ntpd[8263]: 0.0.0.0 c615 05 clock_sync 15 Mar 20:03:56 ntpd[8263]: 0.0.0.0 0618 08 no_sys_peer # ntpq -pn remote refid st t when poll reach delay offset jitter == 192.168.2.254 .DCFa. 1 u 52 6419.115 -0.233 0.001 fe80::202:a5ff: LOCAL(0)11 u 14 1677.196 -26.854 7.523 So it seems to only affect ntp when it's started from systemd? -- Per Jessen, Zürich (11.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] NTP on nanopi neo (air) ?
I don't seem to be able to run NTP on my nanopi neo air - when I try to start it, it enters a loop of stopping and starting, reporting "0.0.0.0 c01d 0d kern kernel time sync disabled". If I do a single-shot "ntpd -g -q", it works. The RTC seems very stable and I don't need microsecond accuracy, so a once-a-day "ntpd -g -q" would probably be enough. Still, I'd like to run ntp - is this some sort of hardware support issue? AFAICT, the Allwinner H3 does have an RTC. >From dmesg: [6.850728] sun6i-rtc 1f0.rtc: rtc core: registered rtc-sun6i as rtc0 [6.850736] sun6i-rtc 1f0.rtc: RTC enabled Thanks for your suggestions. -- Per Jessen, Zürich (6.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] nanopi neo air [SUCCESS]
Per Jessen wrote: > Per Jessen wrote: > >>>> I figured from there it couldn't be too difficult getting u-boot >>>> installed, and ROOT+BOOT partitions updated and maybe have a >>>> somewhat >>>> working system. I'm still waiting for the ttl serial interfaces to >>>> arrive :-) >>> >>> They arrived From China this morning - the board is booting: >>> >>> https://files.jessen.ch/nanopi-neo-air-console.txt >> >> After amending boot.script and >> >> removing "size=100%" from rootflags, and adding "root=/dev/mmcblk0p2" >> to the kernel arguments, the system actually completed boot-up and >> offered me a login. I don't have a network yet, and there were a few >> things that failed during startup (due to root being read-only), but >> I'm running openSUSE TW on the nanopi-neo-air and even have a >> brightly lit green LED. > > After finally finding wifi firmware and NVRAM defs at > http://vps.vdwaa.nl/~jelle/brcm/ > > adding crda and wireless-regedb, I now have a wifi connection, > although I cannot login over ssh yet. (it just hangs). Some sort of ipv4/ipv6 problem - logging in over ipv6 works fine. -- Per Jessen, Zürich (12.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] nanopi neo air [SUCCESS]
Per Jessen wrote: >>> I figured from there it couldn't be too difficult getting u-boot >>> installed, and ROOT+BOOT partitions updated and maybe have a >>> somewhat >>> working system. I'm still waiting for the ttl serial interfaces to >>> arrive :-) >> >> They arrived From China this morning - the board is booting: >> >> https://files.jessen.ch/nanopi-neo-air-console.txt > > After amending boot.script and > > removing "size=100%" from rootflags, and adding "root=/dev/mmcblk0p2" > to the kernel arguments, the system actually completed boot-up and > offered me a login. I don't have a network yet, and there were a few > things that failed during startup (due to root being read-only), but > I'm running openSUSE TW on the nanopi-neo-air and even have a brightly > lit green LED. After finally finding wifi firmware and NVRAM defs at http://vps.vdwaa.nl/~jelle/brcm/ adding crda and wireless-regedb, I now have a wifi connection, although I cannot login over ssh yet. (it just hangs). -- Per Jessen, Zürich (10.9°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] nanopi neo air ?
Per Jessen wrote: > Per Jessen wrote: > >> Andreas Fc3a4rber wrote: >> >>> Just to be clear, this is not just about adding a wlan interface. >>> Since you're the one with the board, I pointed you to look at >>> JeOS-nanopineo as template to create a JeOS-nanopineoair image - >>> don't expect the image for another board to just work for you. LEDs >>> are one of the most common things to differ between boards, compared >>> to serial ports. >> >> I've been trying to do this more or less from scratch - I figure >> that'll >> give me a better overall understanding of what's involved. I'll try >> to sum up where I am at the moment, I would much appreciate someone >> correcting my mistakes/misunderstandings. >> >> I started out here: >> >> https://en.opensuse.org/openSUSE:OpenSUSE_on_your_ARM_board, >> "Bootstrapping a kernel using openSUSE chroot". >> >> I figured from there it couldn't be too difficult getting u-boot >> installed, and ROOT+BOOT partitions updated and maybe have a somewhat >> working system. I'm still waiting for the ttl serial interfaces to >> arrive :-) > > They arrived From China this morning - the board is booting: > > https://files.jessen.ch/nanopi-neo-air-console.txt After amending boot.script and removing "size=100%" from rootflags, and adding "root=/dev/mmcblk0p2" to the kernel arguments, the system actually completed boot-up and offered me a login. I don't have a network yet, and there were a few things that failed during startup (due to root being read-only), but I'm running openSUSE TW on the nanopi-neo-air and even have a brightly lit green LED. -- Per Jessen, Zürich (7.6°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] nanopi neo air ?
Per Jessen wrote: > Andreas Fc3a4rber wrote: > >> Just to be clear, this is not just about adding a wlan interface. >> Since you're the one with the board, I pointed you to look at >> JeOS-nanopineo as template to create a JeOS-nanopineoair image - >> don't expect the image for another board to just work for you. LEDs >> are one of the most common things to differ between boards, compared >> to serial ports. > > I've been trying to do this more or less from scratch - I figure > that'll > give me a better overall understanding of what's involved. I'll try > to sum up where I am at the moment, I would much appreciate someone > correcting my mistakes/misunderstandings. > > I started out here: > > https://en.opensuse.org/openSUSE:OpenSUSE_on_your_ARM_board, > "Bootstrapping a kernel using openSUSE chroot". > > I figured from there it couldn't be too difficult getting u-boot > installed, and ROOT+BOOT partitions updated and maybe have a somewhat > working system. I'm still waiting for the ttl serial interfaces to > arrive :-) They arrived From China this morning - the board is booting: https://files.jessen.ch/nanopi-neo-air-console.txt -- Per Jessen, Zürich (6.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] nanopi neo air ?
Andreas Fc3a4rber wrote: > Just to be clear, this is not just about adding a wlan interface. > Since you're the one with the board, I pointed you to look at > JeOS-nanopineo as template to create a JeOS-nanopineoair image - don't > expect the image for another board to just work for you. LEDs are one > of the most common things to differ between boards, compared to serial > ports. I've been trying to do this more or less from scratch - I figure that'll give me a better overall understanding of what's involved. I'll try to sum up where I am at the moment, I would much appreciate someone correcting my mistakes/misunderstandings. I started out here: https://en.opensuse.org/openSUSE:OpenSUSE_on_your_ARM_board, "Bootstrapping a kernel using openSUSE chroot". I figured from there it couldn't be too difficult getting u-boot installed, and ROOT+BOOT partitions updated and maybe have a somewhat working system. I'm still waiting for the ttl serial interfaces to arrive :-) u-boot - this is installed in a known place in the beginning of the SD card, and the board BIOS knows where to look for it. Is that correct? u-boot - does not seem to be platform specific? I've looked at u-boot in OBS, all the variations link to u-boot, where the spec file has a few platform-specific customizations. It seems to me that nanopi-neo ought to work with nanopi-neo-air too? dtb file - this is a hardware description needed because embedded platforms typically don't offer the interfaces for the OS to discover the hardware itself. The dtb file is part of the kernel tree. I've found a kernel patch for adding a dtb for the nanopi-neo-air. It applied cleanly to 4.10.1. When booting, how is the correct dtb file loaded? thanks Per -- Per Jessen, Zürich (4.4°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] nanopi neo air ?
Andreas Fc3a4rber wrote: >>> In the meantime you should create an HCL:Nano_Pi_Neo_Air Wiki page >>> to track any package or upstream dependencies for creating that >>> image. >> >> I tried that, I'm not sure if it worked. > > Apparently not under that name, and I realize HCL:NanoPi_Neo_Air > would've been more consistent anyway. If you chose a different name, > it doesn't show up here: https://en.opensuse.org/Category:ARM_devices > But maybe you just forgot to tag the category? Not sure what happened to the page yesterday, but I've created a new one. -- Per Jessen, Zürich (4.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] nanopi neo air ?
Andreas Fc3a4rber wrote: > Am 26.02.2017 um 19:00 schrieb Per Jessen: >> Per Jessen wrote: >>> Andreas Fc3a4rber wrote: >>>> Am 24.02.2017 um 17:47 schrieb Per Jessen: >>>>> Has anyone been playing with one of these? I'm not making much >>>>> progress myself - eventually I'd like to get openSUSE running of >>>>> course, but for starters, I'm just trying with the ubuntu core >>>>> from http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air >>>>> >>>>> The device seems to be booting (blue light flashing), but it's not >>>>> picking up an IP-address from dhcp. >>>> >>>> Have you looked at my JeOS-nanopineo? Should be fairly similar. >>> >>> I'll try that - it can't be too difficult to add in a wlan >>> interface. > > Just to be clear, this is not just about adding a wlan interface. > Since you're the one with the board, I pointed you to look at > JeOS-nanopineo as template to create a JeOS-nanopineoair image Ah, I misunderstood. Is there a howto for me to study somewhere, this is brand new territory for me. > LEDs are one of the most common things to differ between boards, > compared to serial ports. Okay. > In the meantime you should create an HCL:Nano_Pi_Neo_Air Wiki page to > track any package or upstream dependencies for creating that image. I tried that, I'm not sure if it worked. -- Per Jessen, Zürich (4.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] nanopi neo air ?
Per Jessen wrote: > Andreas Fc3a4rber wrote: > >> Am 24.02.2017 um 17:47 schrieb Per Jessen: >>> Has anyone been playing with one of these? I'm not making much >>> progress myself - eventually I'd like to get openSUSE running of >>> course, but for starters, I'm just trying with the ubuntu core from >>> http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air >>> >>> The device seems to be booting (blue light flashing), but it's not >>> picking up an IP-address from dhcp. >> >> Have you looked at my JeOS-nanopineo? Should be fairly similar. > > I'll try that - it can't be too difficult to add in a wlan interface. Quick follow-up - it was a little tricky, but at least the nanopi neo air is now running with the ubuntu core image as provided by friendlyarm. For the wifi interface, it's using a "bcmdhd" module from wireless/bcm4336/bcmdhd.ko - afaict, that is not included in the openSUSE JeOS image? For my purposes, I can no doubt make it work with Ubuntu, but I'd much rather be running openSUSE :-) -- Per Jessen, Zürich (7.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] nanopi neo air ?
Andreas Fc3a4rber wrote: > Am 24.02.2017 um 17:47 schrieb Per Jessen: >> Has anyone been playing with one of these? I'm not making much >> progress myself - eventually I'd like to get openSUSE running of >> course, but for starters, I'm just trying with the ubuntu core from >> http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air >> >> The device seems to be booting (blue light flashing), but it's not >> picking up an IP-address from dhcp. > > Have you looked at my JeOS-nanopineo? Should be fairly similar. > Upstream kernel did not have some drivers yet, there's a bug open > where David is tracking those. > > https://en.opensuse.org/HCL:NanoPi_Neo Yes, I did try that initially (before Sportferien). I've just now downloaded openSUSE-Tumbleweed-ARM-JeOS-nanopineo.armv7l-2017.01.17-Build5.2.raw.xz copied it to the SD card, and added /etc/sysconfig/network/ifcfg-wlan0 Boot-up - the green LED comes on at low intensity, then goes high after a little while. The blue LED never lights up and it doesn't request an IP-address. That's why I switched to the Ubuntu core from friendlyarm. I must be missing something essential, I just can't put my finger on it. -- Per Jessen, Zürich (5.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] nanopi neo air ?
Andreas Fc3a4rber wrote: > Am 24.02.2017 um 17:47 schrieb Per Jessen: >> Has anyone been playing with one of these? I'm not making much >> progress myself - eventually I'd like to get openSUSE running of >> course, but for starters, I'm just trying with the ubuntu core from >> http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air >> >> The device seems to be booting (blue light flashing), but it's not >> picking up an IP-address from dhcp. > > Have you looked at my JeOS-nanopineo? Should be fairly similar. I'll try that - it can't be too difficult to add in a wlan interface. Thanks Per -- Per Jessen, Zürich (6.3°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] nanopi neo air ?
Has anyone been playing with one of these? I'm not making much progress myself - eventually I'd like to get openSUSE running of course, but for starters, I'm just trying with the ubuntu core from http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air The device seems to be booting (blue light flashing), but it's not picking up an IP-address from dhcp. -- Per Jessen, Zürich (6.7°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] NTP service fails to start
Volker Kuhlmann wrote: > On Fri 27 Mar 2015 00:41:35 NZDT +1300, Per Jessen wrote: > >> Try 'cnf'. (command-not-found). > > Well I have to laugh: > > # cnf > -bash: cnf: command not found > > And cry: > > # zypper in cnf > 'cnf' not found in package names. Trying capabilities. > No provider of 'cnf' found. try "zypper in command-not-found" On a desktop it's installed by default. -- Per Jessen, Zürich (6.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] NTP service fails to start
Volker Kuhlmann wrote: > On Thu 26 Mar 2015 20:27:27 NZDT +1300, Alexander Graf wrote: > >> Please find out which package it is, so we can add it to the list. Or >> poke the maintainer of the ntpd package to add an explicit dependency >> on logger in his package. > > It's probably not as straightforward, hence my post. > > It's not in any package in factory: > > # zypper in logger > Loading repository data... > Reading installed packages... > 'logger' not found in package names. Trying capabilities. > No provider of 'logger' found. > Resolving package dependencies... > Nothing to do. > > On oS 12.3: > > rpm -qf /usr/bin/logger > util-linux-2.21.2-10.2.1.x86_64 > > # rpm -q util-linux > util-linux-2.26-1.1.armv7hl > > On oS 13.2: > > rpm -qf /usr/bin/logger > util-linux-systemd-2.25.1-2.4.x86_64 > > # zypper in util-linux-systemd > (1/1) Installing: util-linux-systemd-2.26-1.1 .[done] > > # systemctl restart ntpd > > Works. > > So, zyppers' trying of capabilities sucks ;-) > > Package ntp is missing a dependency on util-linux-systemd (or logger). > While logger was in util-linux it was obviously never noticed. > > Both the above are probably not ARM specific. > > https://bugzilla.novell.com/show_bug.cgi?id=924451 > > > Thanks for the pointer. General problem: How do I find out which > package provides XX if zypper (and yast??) can't find it? Try 'cnf'. (command-not-found). -- Per Jessen, Zürich (7.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] NTP service fails to start
Alexander Graf wrote: > > > >> Am 26.03.2015 um 03:38 schrieb Volker Kuhlmann >> : >> >> The NTP daemon doesn't start >> >> journalctl -xn shows: >> >> Mar 26 15:13:45 linux start-ntpd[1779]: /usr/sbin/start-ntpd: line >> 144: logger: command not found Mar 26 15:13:45 linux systemd[1]: >> Failed to start NTP Server Daemon. >> >> Yep no logger command, and no rpm providing it (on 12.3 it's in >> util-linux). It seems like an essential command - is it missing >> deliberately? > > Ouch. It probably got moved into another package and nobody updated > the JeOS package list to include it. logger is in util-linux-systemd. -- Per Jessen, Zürich (6.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Indebted for driving on toll road #0000689285
Tony Su wrote: > In the first place, this is a virus. I was curious about the > attachment which was found to be malware by AV. > In the second place, this is a weird message to be sent to an email > list. The List Admins for this list need to inspect how this message > was accepted to the List (inspect message headers, don't rely on > return address) and likely blacklist the origin. Presumably this list is open, i.e. not subscriber-only. As for blacklisting, that will not do much good - the sender address ist most likely forged. -- Per Jessen, Zürich (8.3°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] chroot - /bin/bash not found?
For getting my Minix Neo X7 to run openSUSE, I have been using the chroot method as described here: http://en.opensuse.org/HCL:Chroot It has worked quite well on my laptop, but today I wanted to move it to a different machine. So I grabbed the latest rootfs image: openSUSE-13.1-ARM-JeOS.armv7-rootfs.armv7l-1.12.1-Build33.1.tbz With this when I try to chroot, I get "/bin/bash not found". With Build32 it works though: openSUSE-13.1-ARM-JeOS.armv7-rootfs.armv7l-1.12.1-Build32.2.tbz -- Per Jessen, Zürich (12.7°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] no Makefiles in kernel-source ?
Guillaume Gardet wrote: > > Le 28/03/2014 08:31, Per Jessen a écrit : >> Yesterday I installed kernel-source - I was surprised to see that the >> source tree didn't contain any Makefiles? What else do I need to >> install? >> >> > > Maybe kernel-default-devel? Something went wrong during the initial install, I've now removed and re-installed, no problems. -- Per Jessen, Zürich (10.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] no Makefiles in kernel-source ?
Yesterday I installed kernel-source - I was surprised to see that the source tree didn't contain any Makefiles? What else do I need to install? -- Per Jessen, Zürich (6.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Minix NEO X7 (Cortex A9 RK3188) ?
Guillaume Gardet wrote: > Hi, > > Le 27/03/2014 11:13, Floris Groenendijk a écrit : >> Hello guys. >> >>> Success! I've got openSUSE 12.3 with a working xfce desktop now. I >>> don't have wifi nor ethernet and sofar I haven't been able to hook >>> up an external harddrive. >> >> I have a Neo Minix X7mini and I got wifi working. >> >> I do have to lookup which git repo I've been using for the kernel if >> you're interested. Currently I have Picuntu running on the minix so >> will have to put the suse rootfs on there first to be helpful >> otherwise. Picuntu is setup on the nand in stead of the sdcard. > > Would be nice to make a new image supporting this device. > > Could you provide us information on how you setup your SD card, which > u-boot/kernel sources you used in order to build a proper openSUSE > image? At least, it could help other people to get openSUSE (or other > Linux flavours) on this device. Here is what I did yesterday - the rootfs is openSUSE-12.3-ARM-XFCE-rootfs.armv7l-1.12.1-Build49.tbz The kernel sources I used: Linux3188-master.zip from https://github.com/Galland I did make quite a few changes to the config, I can submit mine if that's useful. /Per -- Per Jessen, Zürich (6.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
RE: [opensuse-arm] Minix NEO X7 (Cortex A9 RK3188) ?
Floris Groenendijk wrote: > Hello guys. > >> Success! I've got openSUSE 12.3 with a working xfce desktop now. I >> don't have wifi nor ethernet and sofar I haven't been able to hook up >> an external harddrive. > > I have a Neo Minix X7mini and I got wifi working. > > I do have to lookup which git repo I've been using for the kernel if > you're interested. Currently I have Picuntu running on the minix so > will have to put the suse rootfs on there first to be helpful > otherwise. Picuntu is setup on the nand in stead of the sdcard. Thanks Floris - I also did look at Picuntu for a bit,, but went with openSUSE in the end. For now, I'm running openSUSE form the sdcard, but I intend to move it to nand. -- Per Jessen, Zürich (6.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Minix NEO X7 (Cortex A9 RK3188) ?
Per Jessen wrote: >> >> You should enable the right options in your kernel I guess. ;) >> Probably in USB and in Input devices. > > Yep, I've been working on that all day. > >> You may also try our kernel-default which should support Rockchip >> SoC. > > I think I looked at it yesterday, but I didn't see any option for > Rockchip. Instead I went with an older source package, > > https://github.com/Galland/Linux3188.git Success! I've got openSUSE 12.3 with a working xfce desktop now. I don't have wifi nor ethernet, and sofar I haven't been able to hook up an external harddrive. YaST looked quite different, is this something I ought to report? I'm very new to ARM, is there anything like an lspci to tell me what hardware I have? -- Per Jessen, Zürich (3.9°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Minix NEO X7 (Cortex A9 RK3188) ?
Guillaume Gardet wrote: > > Le 26/03/2014 10:03, Per Jessen a écrit : >> Guillaume Gardet wrote: >> >>> Hi, >>> >>> Le 24/03/2014 11:53, Per Jessen a écrit : >>>> (newbie alert) >>>> >>>> I've have just acquired one of these with the intention of running >>>> openSUSE+mythtv on it. I have a c't article on how on to install >>>> Debian on the X5, any other resources I should be studying? >>>> >>> AFAIK, there is no pre-built image for this device. >>> So, you have to download the root file system (rootfs) available at >>> >> http://download.opensuse.org/ports/armv7hl/distribution/13.1/appliances/ >>> (openSUSE-13.1-ARM-JeOS.armv7-rootfs.armv7l*.tbz). And make your own >>> SD card to boot on, with first bootloader (manufacturer specific), >>> U-Boot (configured for your board) and a kernel (configured for your >>> board). >> Yeah, I saw this on http://en.opensuse.org/HCL:Chroot. It wasn't >> really very helpful, but I'm making progress - >> >> using qemu-arm, I've built a kernel based on the rk3088 sources (Neo >> X5). Adding the somewhat iffy instructions from c't on how to build a >> recovery image, and googling how to using the rkflashtool, I have >> just now succeeded in booting up getting YaST started. Unfortunately >> my wireless keyboard isn't working :-( but I'm sure I can get that >> sorted out. > > You should enable the right options in your kernel I guess. ;) > Probably in USB and in Input devices. Yep, I've been working on that all day. > You may also try our kernel-default which should support Rockchip SoC. I think I looked at it yesterday, but I didn't see any option for Rockchip. Instead I went with an older source package, https://github.com/Galland/Linux3188.git -- Per Jessen, Zürich (7.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Minix NEO X7 (Cortex A9 RK3188) ?
Guillaume Gardet wrote: > Hi, > > Le 24/03/2014 11:53, Per Jessen a écrit : >> (newbie alert) >> >> I've have just acquired one of these with the intention of running >> openSUSE+mythtv on it. I have a c't article on how on to install >> Debian on the X5, any other resources I should be studying? >> > > AFAIK, there is no pre-built image for this device. > So, you have to download the root file system (rootfs) available at > http://download.opensuse.org/ports/armv7hl/distribution/13.1/appliances/ > (openSUSE-13.1-ARM-JeOS.armv7-rootfs.armv7l*.tbz). And make your own > SD card to boot on, with first bootloader (manufacturer specific), > U-Boot (configured for your board) and a kernel (configured for your > board). Yeah, I saw this on http://en.opensuse.org/HCL:Chroot. It wasn't really very helpful, but I'm making progress - using qemu-arm, I've built a kernel based on the rk3088 sources (Neo X5). Adding the somewhat iffy instructions from c't on how to build a recovery image, and googling how to using the rkflashtool, I have just now succeeded in booting up getting YaST started. Unfortunately my wireless keyboard isn't working :-( but I'm sure I can get that sorted out. -- Per Jessen, Zürich (4.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] Minix NEO X7 (Cortex A9 RK3188) ?
(newbie alert) I've have just acquired one of these with the intention of running openSUSE+mythtv on it. I have a c't article on how on to install Debian on the X5, any other resources I should be studying? -- Per Jessen, Zürich (5.7°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
