mboehmer

Members
  • Content Count

    130
  • Joined

  • Last visited

Everything posted by mboehmer

  1. 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). Instea
  2. We are down... and modules seem to be in good shape. Let's hope the powerup will work as expected.
  3. 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
  4. 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 ... OK I 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
  5. The schematic is not under NDA; but under gentlemen's agreement. I have to ask first.
  6. 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 dts_orig.txt
  7. 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
  8. 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
  9. 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...
  10. 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-0198
  11. Do 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?
  12. /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 unkn
  13. "Stable" stuff. I have seen worse things on commercial boards. How can I extract the DTB?
  14. Hi, I'm using Windows Just kidding, no. The web editor here lured me to follow its "drag your file here"
  15. I tried to re-upload by drag'n'drop, and again it is empty. Something doesn't like it.
  16. rk3288.txtHi all, I stumbled across a board which may be of interest for one of my next projects. Here you can find a link to it, it is model JLD076 I have the board already on my desk, and as it is really well equipped with loads of interfaces, I would love to get Armbian working on it. J have attached the boot log from console to the message, it uses Uboot 2017, and seems to be based on a standard Rockchip eval board. Onboard peripherials are handled by the usual suspects: ethernet by RTL8211, WiFi by RTL8732, and some of the display links by ALC6540. eMMC
  17. Hi all, as a small status update on the seafloor business, here are some pictures of the new Odroid C2 based instruments which will be deployed in September/October in the northers Pacific. Ten modules with different functionality will be deployed, all based on a standard setup of Odroid C2, TRB3sc FPGA based TDC DAQ system, one PADIWA preamp, and a modded mdedia converter serving as a fully configurable mini switch. One of the modules carries several Hamamatsu mini spectrometers, as well as a camera, to observe bioluminescence. Anoth
  18. mboehmer

    Odroid C4

    Hm. How about starting with the existing problems (like the 1.8V/3.3V switching for the uSD card), before you try to find out something about the CPU instruction set? A system not being able to properly reboot with uSD card will not be of use forf anyone. Seems like you know what you are doing, so you help us here.
  19. mboehmer

    Odroid C4

    For 5.6 kernel attached. I have no 5.4 system running,. Hope it helps nevertheless. 5.6.txt
  20. mboehmer

    Odroid C4

    Which kernel / Uboot did you use for compiling? I assume you compiled a complete image? WIth eMMC reboot works like a charm (tried Hardkernel eMMC 16GB, as well as Radxa ones), with uSD cards it fails every time. I assume we need to make sure that Uboot switches the card to 3.3V mode during startup. Putting this into the kernel is dangerous, as the reboot may or may not happen by software.
  21. mboehmer

    Odroid C4

    As we know now where the uSD card problem resides, is there anyone working on that already?
  22. mboehmer

    Odroid C4

    Some news: it is not the TEST_N pin. There is no pulse or noise visible which could reset the CPUs. I will check the VDDIO_AO next, which could cause a reset also. Only glitch so far I have seen: Amlogic recommends a 1nF cap on RESET_N line, which is missing in the C4. Can anyone explain at what point of the boot sequence the "SM1:" message is being generated? Any clues for a reset source hitting here?
  23. mboehmer

    Odroid C4

    If you take a look on my previous post, it looks like the bootloader starting, and then being broken by a reset, immediately following a new boot attempt. The "normal" boot messages are like that (cold starting a 5.x kernel from uSD card): SM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:F;RCY:0;EMMC:800;NAND:81;SD?:0;SD:0;READ:0;0.0;CHK:0; bl2_stage_init 0x01 bl2_stage_init 0x81 hw id: 0x0000 - pwm id 0x01 bl2_stage_init 0xc1 bl2_stage_init 0x02 Doing a "reboot" or "shutdown -r now" as root leads to the following messages, compare the "hw id" line: [ 95.523748] reboot:
  24. mboehmer

    Odroid C4

    Made some tests now with Armbian 20.05.2 and 4.9.224-odroidc4 - reboot works with uSD cards. For me it looks like a timing problem in Uboot... I will have to make some measurements on uSC pins to see if the problem can be seen there. Removing the uSD card after the first boot attempt and reinserting it doesn't help, power cycle is needed.