Jump to content

martinayotte

Members
  • Posts

    3892
  • Joined

  • Last visited

Posts posted by martinayotte

  1. 2 hours ago, tkaiser said:

    To avoid specific devices, eg. don't buy OPi Zero Plus 2 H5 but H3 instead since the latter is suitable for specific use cases while the H5 variant simply will suck forever.

    Why H5 variant sucks ?

    We first added the OPiPC2, then we added ZeroPlus2-H5 ... They are working fine.

    Of course, the DRAM size is a limitation. We should also limit our expectations ... ;)

  2. Funny guy !

    Since he was the OP, he still had the right to change the thread title from "dwmac-sun8i" to "problems-with-orange-pc" within minutes after I said that he hijacked the thread ...

     

    EDIT : oouups ! I think it is one of the moderators that decide to split the thread ...

     

  3. (btw, you don't need to post in BOLD)

     

    It is stricly impossible that you got an Chinese Android from Armbian build, and if you had flash the eMMC, this Android should never came up !

    So, you simply did NOT succeed to flash eMMC !

     

    (... and you didn't answered if you plugged a USB Serial and capture boot log to prove your facts ...)

     

    (@op1tjaap is right, you seems to hijack this thread : do you known what dwmac-sun8i driver is ?)

  4. This screenshot is for sure the stock Android from eMMC !

    If you are not a beginner with Linux and SBC, then you should have already hooked-up an USB Serial on the Debug Serial Port !

    You will see that it is booting for sure from eMMC ...

     

  5. As I said above, pyspiflash is a good library for that. Plain "C" could achieve that too, but you will need to find library to ease development.

    The protocol mentioned is only related to SPIFlashes. SPI itself doesn't have any protocol other than describing how serialization is done.

    The protocols are defined by the slave devices, for example, a SPI SDCard, or a SPI LCD Display have there own different protocols, although they can be attached on the same SPI bus.

     

  6. I think you misunderstood how SPIFlashes are working. Even if you write into /dev/spidevX-X, it doesn't write into SPIFlash.

    It is simply sending the stream of data over the SPI bus, but the device, SPIFlash, doesn't understand that stream since it is not containing the proper command, since the stream is purely garbage.

    For example, to write a sector in SPIFlash, it is expecting to receive the write-enable command 0x06, then block-erase 0x20 followed by block number, then byte-page-program 0x02 along with address, and the 256 data bytes.

     

  7. How do you use "dd" for that ?

    You can not use "dd" directly with /dev/spidevX-X, since it doesn't handle SPIFlash commands ...

    Either you use "flashrom" utility to write whole image or use python pyspiflash library and manage sector/page erase/read/write yourself.

    Don't expect been able to use it as filesystem, first because MTD partition kernel driver is probably not in Legacy builds, and second because those SPIFlash are pretty small.

    Those SPIFlash are ususally present to place U-Boot bootloader to allow booting from other devices such USB Storage or Network share.

     

  8. For the /boot/bin.old, I will leave the question to other people, since I'm not using any Legacy builds but only Mainline ... (sorry for not providing answer here)

     

    You said that you've replaced UUID by /dev/mmcblk0p1 and still doesn't work ... uuummm ! strange ...

    Could you copy/paste your /etc/fstab ?

    (I bet that perhaps you did a common mistake by leaving the word "UUID=/dev/mmcblk0p1", it should be "/dev/mmcblk0p1" alone without the word UUID)

  9. Yes, I've read the whole thread, but the message "waiting for root file system" and hanging there proved that it is NOT a network issue (trust me here), but the fact that it doesn't find the rootfs partition.

    There seems a mismatch between rootdev found armbianEnv.txt and the one present in /dev/fstab ...

     

    EDIT : The fact that network is not running is simply due to that network services are not started yet since kernel still wait for rootfs to be mounted, waiting forever ...

  10. You can not use "gpio-keys" and "plain sysfs gpio" at the same time. You need to choose on or the other.

    With "gpio-keys", you can check events with "evtest".

    To use your "gpio_watch" application, you will need to remove all the things you've added to DTS.

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines