Hi,
Just asking if this is only me or it's a wider problem: I recently
updated my cubox-i with zypper, pulling in kernel-default-4.4.114, and
after reboot the box boots, but several drivers are missing, so there is
no wired ethernet, no mmcblk, etc.
After booting and waiting for a while, dmesg starts to complain about
driver detection did not finish in time (sadly I don't have the
backtrace at hand, it already went out of the buffer of the serial
console).
For now I worked around the problem this way:
- download the repo-oss (ie. non-update) kernel-default-4.4.76 rpm on an
other machine, copied it to an usb stick
- install the old kernel-default from the usb stick
- copy the /boot from the root fs to the usb stick
- use the other machine to update the /boot on the mmcblk device where
u-boot reads it
So is this only me or do other cubox-i users see the same?
Thanks,
Miklos
Hi Guillaume,
To your question on IRC:
> [14:37:37] <guillaume_g> dirk: is there a mean to be scheduled only on one type of machine (e.g. TX1 or TX2) in OBS? Maybe there is a flag or something?
> [14:40:41] <guillaume_g> it would be for next VPP version, which perform some runtime checks at configure and if scheduled on TX1 (and maybe HiSi) it would not run on other machines. And if it is build on TX2 (or others), it would not be efficient on TX1.
That sounds like we'd (short term) need to patch the configure script to
explicitly be tuned for a particular target platform. Then build the
binary n times - one for each optimization target.
The long term fix is to work with OSEC for example and make sure that
this becomes a real runtime check via IFUNCs for example, nothing
checked at compile time. The same binary ideally runs fast everywhere then.
Alex
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi,
On my Chromebook ARM, hctosys does not wait that /dev/rtc0 appears and fails on rtc0 opening as it is not accessible at this point. See my dmesg:
[ 7.026205] hctosys: unable to open rtc device (rtc0)
[ 9.474121] max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
The RTC appears 2.5 sec after hctosys failed. This is because i2c module is needed and is loaded at this time.
Any idea how to fix/workaround that?
Thanks,
Guillaume
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
I finally have had some time to try to get opensuse Tumbleweed to boot on my
2Gb rock64.
The image I used was downloaded from:
https://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/
Rockchip/images/
After dd'ing the image to the emmc, I installed the Arch u-boot using this
install guide:
https://archlinuxarm.org/platforms/armv8/rockchip/rock64
Using these kernel arguments in grub2/grub.cfg . I'm able to see where the
boot process stops:
$linux ($root)//Image-4.19.5-1-default ${extra_cmdline} loglevel=7
earlycon=uart8250,mmio32,0xff130000 console=ttyS0,1500000n8 splash=silent
plymouth.enable=0 root=UUID=d90c3637-cea7-412c-8aa7-e3a5a47dad39 rw
So after unpacking the initramfs, it stops after saying it can't open the rtc.
[ 29.068003] Freeing initrd memory: 30036K
[ 29.071144] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7
counters available
[ 29.072396] kvm [1]: 8-bit VMID
[ 29.074816] kvm [1]: vgic interrupt IRQ1
[ 29.075557] kvm [1]: Hyp mode initialized successfully
[ 29.081276] Initialise system trusted keyrings
[ 29.082177] workingset: timestamp_bits=44 max_order=19 bucket_order=0
[ 29.083355] zbud: loaded
[ 29.086027] pstore: using deflate compression
[ 29.101879] Key type asymmetric registered
[ 29.102309] Asymmetric key parser 'x509' registered
[ 29.102901] Block layer SCSI generic (bsg) driver version 0.4 loaded (major
244)
[ 29.103982] io scheduler noop registered
[ 29.104388] io sched[ 29.104995] io scheduler cfq registered (default)
[ 29.105[ 29.105954] io scheduler bfq registered
[ 29.115404] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[ 29.136242] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[ 29.163163] Serial: AMBA driver
[ 29.164563] msm_serial: driver initialized
[ 29.167928] cacheinfo: Unable to detect cache hierarchy for CPU 0
[ 29.170729] libphy: Fixed MDIO Bus: probed
[ 29.172295] mousedev: PS/2 mouse device common for all mice
[ 29.181473] ledtrig-cpu: registered to indicate activity on CPUs
[ 29.182859] EFI Variables Facility v0.08 2004-May-17
[ 29.183463] efivars: get_next_variable: status=8000000000000007
[ 29.184227] hidraw: raw HID events driver (C) Jiri Kosina
[ 29.189808] NET: Registered protocol family 10
[ 29.227610] Segment Routing with IPv6
[ 29.230255] registered taskstats version 1
[ 29.230691] Loading compiled-in X.509 certificates
[ 29.231347] zswap: loaded using pool lzo/zbud
[ 29.261624] cryptd: max_cpu_qlen set to 1000
[ 29.290314] Key type big_key registered
[ 29.318665] Key type encrypted registered
[ 29.319101] AppArmor: AppArmor sha1 policy hashing enabled
[ 29.319728] ima:p found, activating TPM-bypass!
[ 29.320325] ima: Allocated h[ 29.320986] evm: Initialising EVM extended
attributes:
[ 229.321845] evm: security.apparmor
[ 29.322192] evm: security.61] evm: HMAC attrs: 0x1
[ 29.370627] hctosys: unable to open rtc device (rtc0)
checking for rtc in the device tree blob show no entry:
fdtdump rk3328-rock64.dtb |grep rtc
Checking the kernel config does show 2 entries:
cat config-4.19.5-1-default |grep rtc
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_SYSTOHC_DEVICE="rtc0"
Where do I go from here?
Thanks.
Mark
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hello,
I want to debug a kernel problem on a armv7 board. For that I want to
temporary enable the CONFIG_PROVE_LOCKING config. My idea was to branch
the used kernel (lpae) build in obs, add the config to the cloned
kernel, and install then the build result on my board.
I tried to modify the config.tar.bz2 as well as adding the
CONFIG_PROVE_LOCKING=y to the config.addon.tar.bz2. in both cases the
build fails with the same error:
https://build.opensuse.org/package/live_build_log/home:frank_kunz:branches:…
Where do I need to put the configuration change in to get a debug build?
Or is there an other method to prepare that?
Br,
Frank
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hello all,
I own an 11.6" Pinebook 1080p for a few weeks now and have some problems
getting opensuse running on it. Maybe someone can help me figuring out
what is going wrong. I do not have a serial cable.
I am using the latest pine64 image from
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Pin…
and write it to a 32GB sdcard using the openSUSE image writer.
As I could see, these images now contain a sun50i-a64-pinebook.dtb so I
am assuming that they should/could boot on a pinebook.
These are my problems:
1. Whenever I look at an sdcard with a freshly written image using
gparted, gdisk or any other disk utility it says:
"The backup GPT table is not at the end of the disk, as it should be.
Fix, by moving the backup to the end (and removing the old backup)?"
"Yes" or "Ignore"
When I answer "Yes", the card is not recognized afterwards during boot
by the pinebook anymore and the pinebook boots Arch Linux from the
installed emmc.
When I answer "Ignore" the card is recognized during boot by the
pinebook but the screen stays black and no matter how long I wait, the
pinebook does not boot of it.
My questions are, is there something wrong with the image and should I
fix it as above or leave it alone and just use it as it is when the
image writer has finished its job?
2. I am pretty sure that the pinebook can boot from the above mentioned
images because it already did but only _one_ single time and, after that
one time boot event, it never did that again.
I saw openSUSE's grub coming up and the last message I could see was
"Loading initial ramdisk". After that the screen went black and never
came back to life again.
After this single succesful boot I found the root partition enlarged and
a swap partition being added to the sdcard when I looked at it with
gparted afterwards.
I do not recall anymore if I "fixed" the GPT on the card as above under
1. before inserting it into the pinebook or if I left it unchanged but I
am pretty sure that the uboot coming up and starting openSUSE's grub was
the Arch Linux one from the emmc.
However, I was not able to reproduce this behaviour.
What am I doing wrong?
3. After that I tried to start openSUSE's grub with the Arch Linux uboot
on the emmc.
I was able to list the content of the esp on the sdcard from within Arch
Linux's uboot and find the/EFI/BOOT/bootaa64.efi but unable to start it.
Is that possible anyway and how would I do that?
Thanks guys
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi,
In Tumbleweed, latest openSSH update disables root login by default.
So, if you have only 'root' user on your headless system, please run the following command on your system, before running a 'zypper dup':
echo -e "\n# Allow root login on ssh\nPermitRootLogin yes" >> /etc/ssh/sshd_config
Otherwise, you will not be able to login to your system anymore.
If it is too late, please use a local connection (serial or keyboard/screen, if not headless), or edit the /etc/ssh/sshd_config file on your SD card from another computer.
Cheers,
Guillaume
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
I noticed a number of images/support for Banana Pi systems having an armv7
type processor architecture. Also using names with sinovoipbpi in the name of
the image.
This name is also present in information about the Banana Pi M64 of which the
processor architecture is aarch64. There is even an openSUSE Tumbleweed image,
dating a year back, which runs on this system.
Will there be support for the Banana Pi M64 with a more recent image? It does
seem very complicated to have such an image available in the ports repository
for aarch64.
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org