mboehmer
-
Posts
142 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by mboehmer
-
-
Have you tried the etcher software? So far I only use eMMC, but this one works really fine.
-
Did you check console output? This would be really helpful.
-
Hi,
just returned to start working on a FLIR Lepton camera, with Odroid C4, hooked up to SPI (faster than the C2).
WIth the official image from download page (Armbian 22.08 Jammy, kernel 5.10.144) I get the following message on console as soon as I try any access to spidev:[ 77.660325] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 77.666930] Mem abort info: [ 77.670400] ESR = 0x86000004 [ 77.673801] EC = 0x21: IABT (current EL), IL = 32 bits [ 77.677915] SET = 0, FnV = 0 [ 77.681367] EA = 0, S1PTW = 0 [ 77.684796] user pgtable: 4k pages, 48-bit VAs, pgdp=000000000f26b000 [ 77.690454] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 77.697196] Internal error: Oops: 86000004 [#1] PREEMPT SMP [ 77.702645] Modules linked in: spidev rfkill cpufreq_powersave cpufreq_conservative lz4hc lz4hc_compress lz4 snd_soc_hdmi_codec snd_soc_meson_axg_tdmout snd_soc_meson_axg_sound_card snd_soc_meson_g12a_tohdmitx panfrost snd_soc_meson_card_utils gpu_sched snd_soc_meson_codec_glue snd_soc_meson_axg_frddr snd_soc_meson_axg_fifo meson_gxbb_wdt meson_vdec(C) v4l2_mem2mem ir_nec_decoder videobuf2_dma_contig meson_rng dw_hdmi_i2s_audio videobuf2_memops videobuf2_v4l2 videobuf2_common meson_saradc videodev rc_odroid mc meson_ir rc_core snd_soc_meson_axg_tdm_interface snd_soc_meson_axg_tdm_formatter snd_soc_core ac97_bus snd_pcm_dmaengine snd_pcm snd_timer snd soundcore display_connector zram sch_fq_codel ramoops reed_solomon nfsd efi_pstore auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables autofs4 meson_gxl reset_meson_audio_arb rtc_meson_vrtc axg_audio sclk_div clk_phase dwmac_generic realtek dwmac_meson8b [ 77.810859] CPU: 2 PID: 3156 Comm: spidev_test Tainted: G C 5.10.144-meson64 #22.08.2 [ 77.819904] Hardware name: Hardkernel ODROID-C4 (DT) [ 77.824823] pstate: a0400009 (NzCv daif +PAN -UAO -TCO BTYPE=--) [ 77.830777] pc : 0x0 [ 77.835509] lr : meson_spicc_pow2_determine_rate+0x2c/0x40 [ 77.840340] sp : ffff800012eb3920 [ 77.845116] x29: ffff800012eb3920 x28: 0000000000000000 [ 77.849906] x27: ffff000001170800 x26: 0000000000000000 [ 77.854808] x25: 0000000000000000 x24: ffff80001134cdf8 [ 77.860069] x23: 0000000000000002 x22: 0000000000000000 [ 77.865331] x21: ffff800012eb3a70 x20: ffff000000d75f00 [ 77.870594] x19: 0000000000000000 x18: 0000000000000000 [ 77.875854] x17: 0000000000000000 x16: 0000000000000000 [ 77.881115] x15: 0000aaaaaf3a3018 x14: 0000000000000000 [ 77.886376] x13: 0000000000000000 x12: 0000000000000000 [ 77.891637] x11: 0000000000000000 x10: 0000000000000054 [ 77.896898] x9 : 0000000000000001 x8 : 0000000000000001 [ 77.902159] x7 : 00000000ffffffbf x6 : 0000000000000000 [ 77.907421] x5 : 0000000000000000 x4 : ffff800012eb39c0 [ 77.912682] x3 : ffff800012eb3d30 x2 : 0000000000000000 [ 77.917943] x1 : ffff800012eb39c0 x0 : ffff00003f9c9e28 [ 77.923206] Call trace: [ 77.927258] 0x0 [ 77.931291] clk_core_determine_round_nolock.part.30+0x20/0x88 [ 77.935568] clk_core_round_rate_nolock+0x80/0x90 [ 77.940226] clk_mux_determine_rate_flags+0xdc/0x208 [ 77.945145] clk_mux_determine_rate+0x14/0x20 [ 77.949456] clk_core_determine_round_nolock.part.30+0x20/0x88 [ 77.955234] clk_core_round_rate_nolock+0x80/0x90 [ 77.959889] clk_core_set_rate_nolock+0x5c/0x1f0 [ 77.964460] clk_set_rate+0x38/0xa8 [ 77.968504] meson_spicc_transfer_one+0x88/0x300 [ 77.972483] spi_transfer_one_message+0x258/0x4c0 [ 77.977139] __spi_pump_messages+0x34c/0x570 [ 77.981366] __spi_sync+0x1e8/0x220 [ 77.985297] spi_sync+0x30/0x58 [ 77.989235] spidev_sync+0x48/0x80 [spidev] [ 77.993146] spidev_message+0x2e0/0x400 [spidev] [ 77.997026] spidev_ioctl+0x41c/0x848 [spidev] [ 78.001033] __arm64_sys_ioctl+0xa8/0xe8 [ 78.004914] el0_svc_common.constprop.4+0x8c/0x180 [ 78.009656] do_el0_svc+0x24/0x90 [ 78.013090] el0_svc+0x14/0x20 [ 78.016370] el0_sync_handler+0x90/0xb8 [ 78.019747] el0_sync+0x160/0x180 [ 78.023032] Code: bad PC value [ 78.026046] ---[ end trace b73c9916d0bfd2d6 ]---This behaviour affects also simple programs like spidev_test from kernel archive.
I checked the hardkernel image (kernel 4.9) and there the problem is not existing.
Any ideas on that?
Thanks in advance, Michael
-
New information: the "last byte read fixed to 0x00" happens only on slow SPI speeds, to my best knowledge it starts with SPI frequencies slower than 300kHz.
SPI transmissions always work, correct data is sent out and received (according to logic analyzer).
If you want to test it on your own, connect a jumper between pins 19 and 21 on the 40pin expansion header, and use a simple SPI transmission to see if things work.
You need to open the SPI device first. SPI transmissions in my code are limited to 20bytes usually (one MachXO2 FlashROM page write/read).
uint8_t test_spi( int fd, uint8_t size, uint32_t speed ) { uint8_t tx[size]; uint8_t rx[size]; memset(tx, 0xaa, size); memset(rx, 0x55, size); struct spi_ioc_transfer tr = { .tx_buf = (unsigned long)tx, .rx_buf = (unsigned long)rx, .len = ARRAY_SIZE(tx), .delay_usecs = 0, .speed_hz = speed, .bits_per_word = 8, }; if( ioctl(fd, SPI_IOC_MESSAGE(1), &tr) == -1) { return OP_ERROR; } /* print received data */ for( uint8_t i = 0; i < size; i++ ) { printf("%02x ", rx[i]); } printf("\n"); /* print transmitted data */ for( uint8_t i = 0; i < size; i++ ) { printf("%02x ", tx[i]); } printf("\n"); return OP_OK; }
-
I just came across a bug on C4 SPI - it trashes any transfer with 16++ bytes by overwriting the last received byte in the RX buffer by 0x00.
Does it make sense at all to file a bug?
Bug can be reproduced by simple means on the board I think (using a MOSI-MISO jumper).
I can provide source code of "broken" SPI call, and logic analyzer shots if needed.
Greetings, Michael
-
I can confirm now a bug in the SPI kernel driver (AFAIK) for Odroid C4.
SPI transfers on Odroid C4 work only reliably with a transfer size of 15 bytes or less.
As soon as a transfer on SPI has more than 15 bytes (i.e. 16++), the last byte of the RX field of the transfer is overwritten by 0x00.
I can see that correct data is being returned by the connected SPI slave on my logic analyzer.
Same user code works without problems on C2 systems.
I can file a bug with extended documentation here.
-
Hi all,
I have upgraded an Odroid C2 setup to C4, and encountered some strange issues.
The SPI interface of C2 is bit banging, while the C4 offers "real" hardware support for SPI.
I use a current kernel (5.10.102) with Bullseye.
I use two SPI /CS lines, while one SPI controller takes care of "user" interaction with the LatticeSemi MachXO2 FPGA on the addon board.
The other SPI controller is used to reflash the MachXO2 by the SPI.
On the C2, everything works fine (while slow, due to bitbanging).
On the C4, the same code on Odroid and FPGA fails - but only on the reflashing interface, not the user interface.
The user interface uses "short" SPI accesses with usually 7 bytes in a command.
The programming interface has long accesses with usually 16bytes++ for writing one 128bit FlashROM pages.
As first result, the last byte of FlashROM page (16bytes) is usually fixed to zero. It seems to happen on readback.
Has anyone encountered similar problems?
Thanks in advance, Michael
-
After "apt update" I made a normal reboot. That was already end of game. Power cycle followed afterwards, with no change in behaviour.
I set up now a new eMMC with normal Focal system (no desktop), and excluded the following files from upgrade:
linux-dtb-current-meson64/focal 20.11 arm64 [upgradable from: 20.08.22] linux-focal-root-current-odroidc4/focal 20.11 arm64 [upgradable from: 20.08.22] linux-image-current-meson64/focal 20.11 arm64 [upgradable from: 20.08.22] linux-u-boot-odroidc4-current/focal 20.11 arm64 [upgradable from: 20.08.22]One of them (or the way it is updated) should be the culprit.
-
Anyone had problems with "apt update / apt upgrade"? Today I updated the packets on my C4, and for some reasons the system didn't boot anymore.
I will try to reproduce with a freshly etched eMMC tonight.
-
Small update on the official image (Armbian 20.08.22 Focal with Linux 5.9.6-meson64): when I boot from eMMC, everything is fine. Inserting a Samsung uSD card leads to repeated "mmc1: error -84 whilst initialization".
Trying to boot from uSD card (same image, working on eMMC) fails. System is stuck with"Starting kernel..." on console.
Attaching the same uSD card by USB card reader works.
So in case you find troubles with uSD card, check brand and product.
-
Hi,
have been off for a few days, too many ongoing projects.
I'm really happy to see that C4 is now "supported", and want to express my thanks to all people involved!
Aynway, a small issue: the download image is reporting to be officially supported, while both selfcompiled images (buster/focal) report themselfs as "trunk" images without official support.
Welcome to Armbian 20.11.0-trunk Buster with Linux 5.9.9-meson64 No end-user support: built from trunkI used a freshly installed build system from yesterday night.
Is this expected behaviour?
The network controller problem (dwmac reset issue) of previous builts is gone, btw. uSD card issues have not been verified, I'm using eMMC on my systems.
So far, Michael
-
HI all,
first of all, I found thi sissue adopting a new board to the CSC tree, done by @balbes150. As it seems to be a problem of RK3288 in general, I post here, in case please move the topic to the approriate place.
I have a JLD076 board, and started adjusting the DTS to the schematic. According to the schematic, and the TRM of RK3289, there is a maximum number of 160 GPIOs.
This is also the number I get from my schematics.
So I expected th get suitable number of pins from gpioinfo (bank:number 0:19, 1:4, 2:18, 3:28, 4:26, 5:12, 6:19, 7:24, 8:10).
Instead, I get listed (0:24, 1...7:32, 8:16).
I tried now to set ngpios for the &gpioX entries in the DTS, both in the rk3288.dtsi and the rk3288-ev-act8846.dts, and verified by dtc that the ngpios entry is in the DTB file, but gpioinfo still shows the wrong number of pins.
This seems to be hardcoded somewhere... any ideas on what I do wrong here?
Best regards, any help is appreciated. Michael
-
We are down... and modules seem to be in good shape. Let's hope the powerup will work as expected.
-
To get things more structured, I start over now, and try to get things done more systematically.
(1) The image found here can't be started from uSD card. I press the maskrom button shortly, following console output, and see that the RK3288 tries to boot from uSD card, but fails.
(2) The images proposed by @balbes150 can be booted from uSD card, by shortly pressing the maskrom button.
(3) A shortly pressed maskrom button forces uSD card booting, a long pressed maskrom button forces the board to go to RKUSB mode.
Edir: @balbes150 is right, it starts also directly from uSD card.
(4) I changed now to Armbian_20.09_Arm-32_bionic_current_5.9.0-rc6.img image from @balbes150. It boots, but lacks ethernet.
Changing the /boot/extlinux/extlinux.conf file to rk3288-evb-act8846.dtb I get ethernet. As the genuine Linaro reports itself as "evb" and carries the ACT8846 I think this is a good starting point.
EDIT: got the versions mixed up. Sorry.(5) Uboot in this image seems to use random MACs, so accessing the board is a bit nasty. is the ethaddr env supported in this Uboot?
EDIT: works like a charm. No more random MACs anymore
I will extend this message with new informations as they arise.
-
I recompiled the DTS and applied it in /boot/extlinux/extlinux.conf and get
ERROR: reserving fdt memory region failed (addr=7df00000 size=d4638) Loading Device Tree to 0f8a1000, end 0f8b77e4 ... OKI will try thw Q8 image now, but it seems to lack ethernet support. Can you add it to the DTB? Otherwise I have to work all over USB serial which is a pain
-
The schematic is not under NDA; but under gentlemen's agreement. I have to ask first.
-
I have extracted the device tree from the eMMC based linux now, and attached it here.
Does this help us?
I have no access to the eMMC partitions for some reasons, as the eMMC partitions are Android type
-
1 hour ago, jock said:
The act8846 is the PMIC controlling the various power supplies of the board components. It decides the voltages of the CPU, logic, GPU, wifi, ethernet and so on.
The image of the above tvbox has already the act8846 kernel module wired and configured via device tree, but it is very important that you have at hand the device tree or the electric schematics of the board to properly configure all the details: as you probably already have seen, the act8846 has various DC-DC converters. The converters supplying high currents (~2A) are usually always wired to the CPU, logic and GPU, but the LDOs may have been attached to different devices, and this could be important to get external devices work, like ethernet, wifi, UHS sdcards, etc...
Thank you for your good explanation.
I'm in contact with @balbes150 already, he helped me a lot. I used one of his images, and could successfully boot the board from uSD card.
My main rror was to keep the maskrom switch pressed too long. If pressed shortly, it forces the RK3288 to skip the eMMC card and use the uSD card instead - it fails to load the kernel directly (as you pointed out) and loads the included 2020 Uboot, which does the rest. If pressed too long, it goes to real MaskROM loader...
AFAIK it is possible to reflash the single sectors of eMMC later with newer Uboot and rootfs?
Some help on how to backup and restore the current image would be great (I did some "backup" by rkdeveltool ( rkdeveloptool rl 0x0 $((7456 * 2048)) backup.data
rkdeveloptool rl 0x0 $((7456 * 2048)) backup.databut I'm not sure if this is really the way to go.
For DTB work, I will need some help, but I have a complete schematics of the board, documentation on how to compile for that specific card, and I already asked the manufacturer for his DTS file.
I think - apart from DTS syntax - there is no problem to get all information.
I would be happy to have some kind of official Armbian build, even if I have to get maintainer
I have started now with rk3288-evb-act8846.dtb, and get ethernet working, other stuff not tried yet.
Maybe you can send me your DTS file to check about ACT8846 stuff first?
-
Any idea on how to prepare a microSD card with all stuff needed?
I can force the board into bootloader mode by a switch, and it tries to boot from uSD card, but fails:
DDR Version 1.06 20171020 In Channel a: DDR3 400MHz Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB Channel b: DDR3 400MHz Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB Memory OK Memory OK OUT Boot1 Release Time: Apr 11 2018 10:32:58, version: 2.36 ChipType = 0x8, 227 mmc2:cmd19,256 SdmmcInit=2 0 BootCapSize=2000 UserCapSize=7456MB FwPartOffset=2000 , 2000 mmc0:cmd5,32 SdmmcInit=0 0 BootCapSize=0 UserCapSize=14924MB FwPartOffset=2000 , 0 StorageInit ok = 178583 tag:LOADER error,addr:0x2000 hdr 032c77e4 + 0x0:0x000081a4,0x00001862,0x5f5179c8,0x5f5179c8, tag:LOADER error,addr:0x4000 hdr 032c77e4 + 0x0:0xa4,0x81,0x00,0x00,0x67,0x03,0x00,0x00,0xc9,0x79,0x51,0x5f,0xc9,0x79,0x51,0x5f, tag:LOADER error,addr:0x2800 hdr 032c77e4 + 0x0:0x000081a4,0x000000f9,0x5f5179c8,0x5f5179c8, tag:LOADER error,addr:0x4800 hdr 032c77e4 + 0x0:0xed,0x81,0x00,0x00,0xfa,0x01,0x00,0x00,0xca,0x79,0x51,0x5f,0xca,0x79,0x51,0x5f, .... -
-
I received full documentation for building the "genuine" LInux of the board (won't start reading now, our deep sea deployment takes place today).
I tried to backup the partition information with this tool, which works for the Android 7.1 board version, but fails on the Linux board version.
Next I will try to get some uSD card image booted...
-
I'm a bit wiser now: in Uboot the partition table is like this:
Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00004000 0x00005fff "uboot" attrs: 0x0000000000000000 type: cb280000-0000-4d3c-8000-7b5800000ab9 guid: dd3d0000-0000-473b-8000-58800000230e 2 0x00006000 0x00007fff "trust" attrs: 0x0000000000000000 type: e86f0000-0000-495e-8000-30c300005377 guid: 42040000-0000-4900-8000-019800001cf7 3 0x00008000 0x00009fff "misc" attrs: 0x0000000000000000 type: 7f330000-0000-4c09-8000-3ab3000015d5 guid: 742c0000-0000-4607-8000-520800000195 4 0x0000a000 0x00019fff "boot" attrs: 0x0000000000000000 type: 372e0000-0000-4d35-8000-55ce00005cfc guid: 1c160000-0000-4611-8000-747800006a10 5 0x0001a000 0x00029fff "recovery" attrs: 0x0000000000000000 type: b96d0000-0000-456b-8000-14bc00004914 guid: e2790000-0000-4074-8000-628f00007f8f 6 0x0002a000 0x00e8ffde "rootfs" attrs: 0x0000000000000000 type: ad500000-0000-4b4d-8000-5d2600000f44 guid: 614e0000-0000-4b53-8000-1d28000054a9 -
1 hour ago, TonyMac32 said:
Model: Evb-RK3288
DRAM: 2 GiB
Relocation Offset is: 7de4d000
Using default environmentDo you think this could work? How can I "swap" the device tree?
I still wait for some information from board vendor, I don't want tp brick it
Would it be possible to manually start a uSD card image from Uboot, instead of fixed eMMC?
-
/boot is empty. Partitions seem to be a bit strange:
Disk /dev/mmcblk2: 7.3 GiB, 7818182656 bytes, 15269888 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 9E460000-0000-470B-8000-0417000014B1 Device Start End Sectors Size Type /dev/mmcblk2p1 16384 24575 8192 4M unknown /dev/mmcblk2p2 24576 32767 8192 4M unknown /dev/mmcblk2p3 32768 40959 8192 4M unknown /dev/mmcblk2p4 40960 106495 65536 32M unknown /dev/mmcblk2p5 106496 172031 65536 32M unknown /dev/mmcblk2p6 172032 15269854 15097823 7.2G unknown/boot is also not mounted in system. Only mounted partition is
/dev/mmcblk2p6 on / type ext4 (rw,relatime,data=ordered)
Odroid C4 & SPI - anyone successful?
in Amlogic meson
Posted
Hi,
after a long time I started up my C4 and tried both the standard download kernel as well as a home compiled one.
I need SPI on the C4, so I changed the device tree to meson-sm1-odroid-c4-spidev.dtb, and see spidev kernel modul loaded, but no driver, and I don't get any signals on the corresponding pins.
Any help is appreciated - would be great to have SPI working again...
See you, Michael