mboehmer

Members
  • Content Count

    78
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Everything posted by mboehmer

  1. HI guys, sorry for not giving earlier feedback (been busy with payload for our sounding rocket, no C2 included this time, guess it doesn't like 15g)... I just created a new image today (ARMBIAN 5.86 user-built Debian GNU/Linux 9 (stretch) 4.19.43-meson64), and console seems to be operational again. Thanks to everybody involved to fix that issue! Michael
  2. Simply said, I want to switch off the C2 by "shutdown -h now" - which seems to work when it is powered by the small connector. If it is powered by +5V pins of expansion port, it doesn't work: it shuts down, enters Uboot and starts again. For our deep sea operation we need both: powering by expansion port, and switching it off reliably. The first version of this board (with old kernel, approx. one year ago) did that job, and as there were no changes on powering scheme on my board, I assume that there is some problem with C2 switching off its power. I think it would be worth checking the AO bank - the "broken" console is there, and the VCCK regulator is being controlled from there. I will try to locate the signal on the PCB and check the signal by scope, in case that helps. EDIT: issue solved. The Odroid C2 doesn't like any voltage applied to GPIOs while it's off. I have two pins which are used to switch a DC/DC converter, in normal operation 3.0V are present there (by 10k0 resistor). This is sufficient to power some stuff inside the SoC and "boot through" in case of powerdown. Lines cut, and shutdown works as expected.
  3. Indeed, the readback of input status revealed it in the end. Could have thought of that earlier. Still, console problem is present, but that's another story. As well, a "shutdown -h now" allows the C2 to reboot, instead of powering down (which is not a good idea in a system on the sea floor).
  4. ISSUE SOLVED. I found a really tiny and well hidden solder bridge on a "strategical" point where the I/O lines 475, 480 and SDA came close (and were not insulated by solder stop due to vias). Using "busybox devmem" I could readback the I/O line states and trace that one back.
  5. Well, fact is, that activating GPIO 475 or 480 (see table above) kills I2C access. Just checked with the logic analyer: exporting the pin doesn't do any harm, chaning its direction to "out" sets SDA low and leaves SCL high. In more details: (1) C2 bootet, i2cdetect finds all I2C slaves, I2C accesses are normal on logic analyzer. (2) exporting 475 doesn't change anything (3) setting 475 as output sets SDA low and leaves SCL high (pullup or active driven? don't know) (4) setting 475 as input again releases the SDA line again (4) I2C works again steps (3) and (4) can be repeated several times, no changes. So for me it looks like the SDA pin direction is "by chance" set also when accessing GPIO 475. Same applies for GPIO 480. If I can provide more input, please let me know. I urgently need working GPIO... EDIT: how can I peek/poke registers on the SoC directly? Would be the easiest way to see changes in I/O registers... EDIT2: busybox is your friend...
  6. Here we are: after booting, I2C works fine, and "cat /sys/kernel/debug/gpio" says: gpiochip1: GPIOs 378-496, parent: platform/c8834000.periphs:pinctrl@4b0, periphs-banks: gpio-378 (Eth MDIO ) gpio-379 (Eth MDC ) gpio-380 (Eth RGMII RX Clk ) gpio-381 (Eth RX DV ) gpio-382 (Eth RX D0 ) gpio-383 (Eth RX D1 ) gpio-384 (Eth RX D2 ) gpio-385 (Eth RX D3 ) gpio-386 (Eth RGMII TX Clk ) gpio-387 (Eth TX En ) gpio-388 (Eth TX D0 ) gpio-389 (Eth TX D1 ) gpio-390 (Eth TX D2 ) gpio-391 (Eth TX D3 ) gpio-392 (Eth PHY nRESET |mdio-reset ) out hi gpio-393 (Eth PHY Intc ) gpio-394 (HDMI HPD ) gpio-395 (HDMI DDC SDA ) gpio-396 (HDMI DDC SCL ) gpio-397 ( ) gpio-398 (eMMC D0 ) gpio-399 (eMMC D1 ) gpio-400 (eMMC D2 ) gpio-401 (eMMC D3 ) gpio-402 (eMMC D4 ) gpio-403 (eMMC D5 ) gpio-404 (eMMC D6 ) gpio-405 (eMMC D7 ) gpio-406 (eMMC Clk ) gpio-407 (eMMC Reset |reset ) out hi gpio-408 (eMMC CMD ) gpio-409 ( ) gpio-410 ( ) gpio-411 ( ) gpio-412 ( ) gpio-413 ( ) gpio-414 ( ) gpio-415 ( ) gpio-416 (SDCard D1 ) gpio-417 (SDCard D0 ) gpio-418 (SDCard CLK ) gpio-419 (SDCard CMD ) gpio-420 (SDCard D3 ) gpio-421 (SDCard D2 ) gpio-422 (SDCard Det |cd ) in hi gpio-423 ( ) gpio-424 ( ) gpio-425 ( ) gpio-426 ( ) gpio-427 ( ) gpio-428 ( ) gpio-429 ( ) gpio-430 ( ) gpio-431 ( ) gpio-432 ( ) gpio-433 ( ) gpio-434 ( ) gpio-435 ( ) gpio-436 ( ) gpio-437 ( ) gpio-438 ( ) gpio-439 ( ) gpio-440 ( ) gpio-441 ( ) gpio-442 ( ) gpio-443 ( ) gpio-444 ( ) gpio-445 ( ) gpio-446 ( ) gpio-447 (I2C A SDA ) gpio-448 (I2C A SCK ) gpio-449 (I2C B SDA ) gpio-450 (I2C B SCK ) gpio-451 (PWM D ) gpio-452 (PWM B ) gpio-453 (Revision Bit0 ) gpio-454 (Revision Bit1 ) gpio-455 ( ) gpio-456 (J2 Header Pin35 |onewire@1 ) in hi gpio-457 ( ) gpio-458 ( ) gpio-459 ( ) gpio-460 (J2 Header Pin36 |onewire@2 ) in hi gpio-461 (J2 Header Pin31 ) gpio-462 ( ) gpio-463 ( ) gpio-464 ( ) gpio-465 (TF VDD En |TFLASH_VDD ) out lo gpio-466 (J2 Header Pin32 ) gpio-467 (J2 Header Pin26 ) gpio-468 ( ) gpio-469 ( ) gpio-470 (J2 Header Pin29 ) gpio-471 (J2 Header Pin24 |cs ) out hi gpio-472 (J2 Header Pin23 |sck ) out lo gpio-473 (J2 Header Pin22 |cs ) out hi gpio-474 (J2 Header Pin21 |miso ) in hi gpio-475 (J2 Header Pin18 ) gpio-476 (J2 Header Pin33 ) gpio-477 (J2 Header Pin19 |mosi ) out hi gpio-478 (J2 Header Pin16 ) gpio-479 (J2 Header Pin15 ) gpio-480 (J2 Header Pin12 ) gpio-481 (J2 Header Pin13 ) gpio-482 (J2 Header Pin8 ) gpio-483 (J2 Header Pin10 ) gpio-484 ( ) gpio-485 ( ) gpio-486 ( ) gpio-487 ( ) gpio-488 ( ) gpio-489 (J2 Header Pin11 ) gpio-490 ( ) gpio-491 (J2 Header Pin7 |onewire@0 ) in hi gpio-492 ( ) gpio-493 ( ) gpio-494 ( ) gpio-495 ( ) gpio-496 ( ) gpiochip0: GPIOs 497-511, parent: platform/c8100000.bus:pinctrl@14, aobus-banks: gpio-497 (UART TX ) gpio-498 (UART RX ) gpio-499 (VCCK En ) gpio-500 (TF 3V3/1V8 En |TF_IO ) out lo gpio-501 (USB HUB nRESET |usb-hub-reset ) out hi gpio-502 (USB OTG Power En |USB_OTG_PWR ) out hi gpio-503 (J7 Header Pin2 ) gpio-504 (IR In ) gpio-505 (J7 Header Pin4 ) gpio-506 (J7 Header Pin6 ) gpio-507 (J7 Header Pin5 ) gpio-508 (J7 Header Pin7 ) gpio-509 (HDMI CEC ) gpio-510 (SYS LED |c2:blue:alive ) out hi gpio-511 ( ) After this little script: #!/bin/sh echo 475 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio475/direction echo 0 > /sys/class/gpio/gpio475/value it says: gpiochip1: GPIOs 378-496, parent: platform/c8834000.periphs:pinctrl@4b0, periphs-banks: gpio-378 (Eth MDIO ) gpio-379 (Eth MDC ) gpio-380 (Eth RGMII RX Clk ) gpio-381 (Eth RX DV ) gpio-382 (Eth RX D0 ) gpio-383 (Eth RX D1 ) gpio-384 (Eth RX D2 ) gpio-385 (Eth RX D3 ) gpio-386 (Eth RGMII TX Clk ) gpio-387 (Eth TX En ) gpio-388 (Eth TX D0 ) gpio-389 (Eth TX D1 ) gpio-390 (Eth TX D2 ) gpio-391 (Eth TX D3 ) gpio-392 (Eth PHY nRESET |mdio-reset ) out hi gpio-393 (Eth PHY Intc ) gpio-394 (HDMI HPD ) gpio-395 (HDMI DDC SDA ) gpio-396 (HDMI DDC SCL ) gpio-397 ( ) gpio-398 (eMMC D0 ) gpio-399 (eMMC D1 ) gpio-400 (eMMC D2 ) gpio-401 (eMMC D3 ) gpio-402 (eMMC D4 ) gpio-403 (eMMC D5 ) gpio-404 (eMMC D6 ) gpio-405 (eMMC D7 ) gpio-406 (eMMC Clk ) gpio-407 (eMMC Reset |reset ) out hi gpio-408 (eMMC CMD ) gpio-409 ( ) gpio-410 ( ) gpio-411 ( ) gpio-412 ( ) gpio-413 ( ) gpio-414 ( ) gpio-415 ( ) gpio-416 (SDCard D1 ) gpio-417 (SDCard D0 ) gpio-418 (SDCard CLK ) gpio-419 (SDCard CMD ) gpio-420 (SDCard D3 ) gpio-421 (SDCard D2 ) gpio-422 (SDCard Det |cd ) in hi gpio-423 ( ) gpio-424 ( ) gpio-425 ( ) gpio-426 ( ) gpio-427 ( ) gpio-428 ( ) gpio-429 ( ) gpio-430 ( ) gpio-431 ( ) gpio-432 ( ) gpio-433 ( ) gpio-434 ( ) gpio-435 ( ) gpio-436 ( ) gpio-437 ( ) gpio-438 ( ) gpio-439 ( ) gpio-440 ( ) gpio-441 ( ) gpio-442 ( ) gpio-443 ( ) gpio-444 ( ) gpio-445 ( ) gpio-446 ( ) gpio-447 (I2C A SDA ) gpio-448 (I2C A SCK ) gpio-449 (I2C B SDA ) gpio-450 (I2C B SCK ) gpio-451 (PWM D ) gpio-452 (PWM B ) gpio-453 (Revision Bit0 ) gpio-454 (Revision Bit1 ) gpio-455 ( ) gpio-456 (J2 Header Pin35 |onewire@1 ) in hi gpio-457 ( ) gpio-458 ( ) gpio-459 ( ) gpio-460 (J2 Header Pin36 |onewire@2 ) in hi gpio-461 (J2 Header Pin31 ) gpio-462 ( ) gpio-463 ( ) gpio-464 ( ) gpio-465 (TF VDD En |TFLASH_VDD ) out lo gpio-466 (J2 Header Pin32 ) gpio-467 (J2 Header Pin26 ) gpio-468 ( ) gpio-469 ( ) gpio-470 (J2 Header Pin29 ) gpio-471 (J2 Header Pin24 |cs ) out hi gpio-472 (J2 Header Pin23 |sck ) out lo gpio-473 (J2 Header Pin22 |cs ) out hi gpio-474 (J2 Header Pin21 |miso ) in hi gpio-475 (J2 Header Pin18 |sysfs ) out lo gpio-476 (J2 Header Pin33 ) gpio-477 (J2 Header Pin19 |mosi ) out hi gpio-478 (J2 Header Pin16 ) gpio-479 (J2 Header Pin15 ) gpio-480 (J2 Header Pin12 ) gpio-481 (J2 Header Pin13 ) gpio-482 (J2 Header Pin8 ) gpio-483 (J2 Header Pin10 ) gpio-484 ( ) gpio-485 ( ) gpio-486 ( ) gpio-487 ( ) gpio-488 ( ) gpio-489 (J2 Header Pin11 ) gpio-490 ( ) gpio-491 (J2 Header Pin7 |onewire@0 ) in hi gpio-492 ( ) gpio-493 ( ) gpio-494 ( ) gpio-495 ( ) gpio-496 ( ) gpiochip0: GPIOs 497-511, parent: platform/c8100000.bus:pinctrl@14, aobus-banks: gpio-497 (UART TX ) gpio-498 (UART RX ) gpio-499 (VCCK En ) gpio-500 (TF 3V3/1V8 En |TF_IO ) out lo gpio-501 (USB HUB nRESET |usb-hub-reset ) out hi gpio-502 (USB OTG Power En |USB_OTG_PWR ) out hi gpio-503 (J7 Header Pin2 ) gpio-504 (IR In ) gpio-505 (J7 Header Pin4 ) gpio-506 (J7 Header Pin6 ) gpio-507 (J7 Header Pin5 ) gpio-508 (J7 Header Pin7 ) gpio-509 (HDMI CEC ) gpio-510 (SYS LED |c2:blue:alive ) out hi gpio-511 ( ) Hope that one helps. Edit: output from 4.19.6 stretch build, neweset kernel has console problems as discussed in other thread.
  7. Will check on Friday, sorry for the delay.
  8. Sorry, wrong thread... I was refering to the interference between I2C and GPIO usage. Time for some days off
  9. Any news on that subject from expert side?
  10. Hi, just could test now the 4.19.6 stretch compilation - that one works as expected, and gives me a console on /dev/ttyAML0. Console works again, I can log in. GPIO problem with I2c interference is still there, i.e. exporting and setting GPIO 475 to out kills I2C access. Michael
  11. I see, you are taking the issue "beer" very serious. But all that bottles seem to share a problem: they are empty For me, my bottles are stored in the cellar - not empty (but opened). But Vodka doesn't expire really while beer does (not in your place, dude, I guess). Starkbier is something which should be enjoyed with care. I remember some American students visiting us when I was a young boy - they made archeological excavations of some Germanic site nearby. We had some barbecue, and my dad served Starkbier instead of the normal "beer" they were used to from the States (and he warned them to take care). It was hell of a fun to watch them after the first bottle...
  12. I may show up sooner or later again in Victoria. Too far from Quebec, I assume - but the Odroids will go to Canadian shore Hefeweizen... yes. We have such kind here. And many more styles, like the Starkbier. Will start some new compilations tomorrow, just finished a test with stretch, but the setup is at university.
  13. Args. More coffee... Need a stretch image. Hope you guys are sometimes around Munich, I owe you a beer or two BTW, where do I find the available version numbers for kernels? Or better, the kernel sources? Maybe I can try to see if there were changes in code to touch AO banks?
  14. Did I tell you already that the build system is really a miracle? Will try, had problems building Jessie today, apparently packages couldn't be downloaded. Starting new attempt right now.
  15. Indeed. Seems to be bank AO related (while that could also be somehow quirky in 5.77, as switching off failed there, too, but that's just my feeling). Is there any way to force the Armbian build system to use an older version? I had 5.77 running at least, so while you look at it (much appreciated!) I could continue with the GPIO stuff.
  16. Another observation, which indicates that the AO bank may have problems: one pin AO_BIT2 is used to control the main DC/DC regulator (VCCK), and switching off the Odroid C2 leads to a reboot instead of shutdown. So my best guess is that something in bank AO goes wrong, and both effects have the same root.
  17. Found something strange in both bionic and jessie dmesg output: [ 1.677916] GPIO line 501 (usb-hub-reset) hogged as output/high [ 1.684494] gxbb-aoclkc c8100000.sys-ctrl:clock-controller: Clock registration failed [ 1.684533] gxbb-aoclkc: probe of c8100000.sys-ctrl:clock-controller failed with error -17 [ 1.685152] soc soc0: Amlogic Meson GXBB (S905) Revision 1f:c (0:1) Detected [ 1.687516] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled According to C2 schematics, UART_AO_A is on AO bank. Maybe we should check on that part? Edit: seems to be located in drivers/clk/meson/meson-aoclk.c, according to the error message meson_aoclkc_probe() failed. Edit: I'm lost in tracing back the error number. Could be KDB_BADREG. Seems to happen in clk_hw_register() or clk_create_clk().
  18. Sir, yes, sir! Edit: I use "stretch", not "jessie". Welcome to ARMBIAN 5.78 user-built Debian GNU/Linux 9 (stretch) 4.19.34-meson64 System load: 0.67 0.28 0.10 Up time: 1 min Memory usage: 4 % of 1976MB IP: 10.162.208.175 CPU temp: 33°C Usage of /: 8% of 15G Edit: bionic compiled. Same result, no console. Welcome to ARMBIAN 5.78 user-built Ubuntu 18.04.2 LTS 4.19.34-meson64 System load: 0.46 0.11 0.04 Up time: 0 min Memory usage: 4 % of 1976MB IP: 10.162.208.175 CPU temp: 27°C Usage of /: 6% of 15G
  19. I have no /dev/ttyAML0 and /dev/ttyAML1 on my Odroid C2.
  20. Sorry, double post. should pick coffee first
  21. I use only eMMC card, no SD cards. I tried with two images, and yes, I use etcher (on Windows, sorry, it's my main machine here). Even tried a different USB serial converter, and checked output of console header with scope. No edges after "starting kernel..." Just for understanding: /dev/tty1 should be routed to the J2 Rxd/TxD pins, so "echo BLA > /dev/tty1" should give some edges on J2 UART?
  22. A lot to learn I have. More complex simple things are. Will try tomorrow morning! EDIT: confirmed working! Thanks
  23. I tried "verbosity=2". With that I don't see any further messagew after "starting kernel...".
  24. Hi, I compiled some images for C2 yesterday (mainline 5.77, jessie), and had a nice console as usual. Today, the new images still have u-boot console, and give some information about kernel starting, but no login by console (USB serial) is possible. I tried to set "console=serial" in /boot/armbianEnv.txt, but that gives me an endless reboot loop. Were there some changes? Maybe in baudrate? I get u-boot messages at 115200 8N1 as expected.. Michael