Jump to content

raidboy

Members
  • Posts

    29
  • Joined

  • Last visited

Posts posted by raidboy

  1. Trying to download armbian for rockpi-4a, following the link https://redirect.armbian.com/rockpi-4a/ on https://www.armbian.com/rock-pi-4/

     

    In one case, this resolves to https://mirrors.netix.net/armbian/dl/rockpi-4a/, which shows an empty directory except for an archive subdirectory that is empty too. clicking around through the armbian/dl folder, this seems to be only empty directories for any board.

     

    In another case, the redirect resolves to https://minio.k-space.ee/armbian which just returns XML gibberish.

     

     

     

  2. ok. copied mmcblk1p1 partition file.

    copied fresh Armbian onto eMMC, booted from it.

    boot from SD again, resize mmcblk1p1 to former size (no change of 32768 start sector), copy back mmcblk1p1 saved partition.

    Boots fine.

    Also was able to add swap partition which automatically got used by armbian.

     

    Might be useful to consider some form of protective partition entry from 2048 to 32767 to avoid this type of mistake to happen...

  3. actually even the SD installation image shows MBR and GPT in gdisk.

     

    Thanks for finding the 2048. No idea, i guess i must have messed um in gparted, didn't mean to move the start of the partition.

     

    So. There is nothing that should make bootstrap fail if i just change at the end of the disk and add partitions there ?

     

    Given how much i changed in my installation i guess i have to simply save the whole FW and restore to a fresh image copy... lets see.

  4. RockPi4a. Installed busster current 5.8.6 armbian onto eMMC. Works fine.

     

    Now i figure out i need swap space (app needs more than the 1G mem i have). So i boot another image from SD an use gparted to shrink the first partition from the end to create 4GByte and create a swap partition in there. Now the board won't boot anymore (see attached file). Erased SPI, no difference.  Partition table shows GPT and "MBR protective" (before and after resizing).

     

    so, whats the magic to create a bootable armbian disk if one needs different partitioning than just the "full disk one partition" layout ? Is this "uboot" hidden behind the only partition, there was a bunch of space unused after the partition that i used for the swap partition.

     

    Sorry if this was discussed before but uncle google and dr armbian search couldn't find anything for me ;-(

     

    armbian-failure.txt

  5. Finally managed to verify the SPI assumption, and it is correct:

     

    Boot radxa debian, e.g.: from SSD

    % cat /proc/mtd
    dev:    size   erasesize  name
    mtd0: 00400000 00001000 "loader"

    This shows that there is a partition? on SPI.  When trying to do the same on Armbian, it will not show the partition.

     

    Erase:

    dd if=/dev/zero ob=/dev/mtdblock0 bs=512

    Use first command to verify its erased.

     

    Afterwards, normal armbian image with only MBR partition table will boot fine from eMMC.

    The modified gpt partition image will still boot too.

  6. Are there any commands to show information that could tell me about the level of power consumption ? E.g.: energy saving state of CPU or the like ?

     

    On the SBC i am using, i think the power consumption is lower when running the same setup with kernel 5.4, and higher with legacy kernel 4.4. Alas, 5.4 has other problems, so i want to try to figure out what settings/features reduce power consumption in 5.4 and maybe i can then configure them equally in 4.4.

     

    This is rockpi4a rockchip3399. If there is nothing generic enough about the topic, i can ask on the forum for that chip.

  7. But why shuold the current file format with MBR and phase 2/3 not continue to work whether SPI is or is not present ? Radxa would just have to fix up their SPI boot loader to recognize MBR and continue to boot from the phase 2/3 on the eMMC. Or for that matter, if there is really no benefit to execute the on-eMMC phase 2/3 (hence my question before) to boot directly into phase 4 on the eMMC as they seem to do now when they discover UEFI. I probably would prefer the latter, if the SPI boot code from radxa could try to find /boot on multiple partition and offer a menu on serial console or even graphics ;-) Then the OSs on those partitions wouldn't have to bother implementing that. Thats a typical platform firmware problem when they want to support multiple different OS simultaneously. Which at least for one partition linux, one partition android might be interesting to users.

     

    Expecting third parties like armbian to do additional install magic like explaining to users what SPI is, how they need to feed and fix is, doesn't sound like a viable way to make users happy. 

  8. Thanks, piter75. You are pointing me to good workarounds, but i think in the first place, radxa needs to explain what the forward going image format is that third party distributions like armbian should use and that will correctly bootstrap across all rockpi4 versions. Seems right now there is no such format and that would be a big pain for distros like armbian or others: you seem to require a standard rockchip setup for rockpi4a without SPI, and another one (UEFI, stage 2,3 on SPI) on v1.4 with som random new radxa code on the SPI. 

     

    Just curious: Is there actually any benefit of having the u-boot stage 3 on the SD/eMMC card, e.g.: does it do any special cool things that the radxa u-boot wouldn't do ? Or is it just there because on rockpi4a without SPI its just mandatory to have _some_ u-boot version on the uSD/eMMC, but theres beside bug-fixes no real feature differences between those u-boot's.

     

    Thanks!

  9. @igor: 

     

    Are you telling me that the armbian images have stage 2 and stage 3 in the sectors before 32768 without showing them in the MBR partition table ? 

     

    Looks to me as if what i am seeing on my rockpi4a looks more like what the documentation describes as boot from "u-disk" with armbian really being stage 4/5 from the single partition it has, and no stage 2/3 taken from the disk before.

     

    I don't even know what a u-disk is.

     

  10. Boot from unchanged armbian image:

     

    http://ix.io/2bjY
     

    (trying to boot from ethernet at the end).

     

    Working boot after replacing MBR with EUFI:

     

    http://ix.io/2bk3
     

    I have no clue about SPI. I just think to remember that booting from MBR on eMMC did work initially, but then i was experimenting with radxas debian installation, and when i installed something with "apt install ..." there was some dependency that took a long time, seemingly flashing something. Thats why i am thinking that i may now have some newer radxa firmware flashed than what the device was shipped with. But i couldn't find any webpage from where i could diagnose the situation ... I'll certainly ask on the radxa forum too.

     

    Took me already the better part of sunday to figure out how to get armbian booting again. *sigh*.

     

  11. Ok, got a second rockpi4a v1.4 1MB RAM, 32 MByte eMMC to play around with, and

     

     Armbian_20.02.0-rc1_Rockpi-4a_bionic_current_5.4.14_minimal.img

     

    is booting fine

     

    http://ix.io/2bgq

     

    after fixing up the UEFI partition table. See:

     

    I can not yet correlate this experience with the prior experience on my other production rockpi4 from the postings above, back on that system i also have 5 SATA HDD connected via a 5 port PCI adapter, whereas i have no optional components connected yet to this rockpi. 

     

     

  12. https://dl.armbian.com/rockpi-4b/Bionic_legacy_desktop

    https://dl.radxa.com/rockpi/images/debian/rockpi4-debian-stretch-desktop-arm64-20190730_2022-gpt.img.gz

    (probably other images too, those are just the two i tried).

     

    Both boot fine when installing/booting on RockPi4a via uSD.

    Both fail to book when installing/booting on RockPI4a vie eMMC (32GByte).

     

    Problem seems to be that bootloader on the rockpi4a seemingly does not want to boot from MBR partition table, but only from GUID partition table. When check the partition table on both of the above images, fdisk/gdisk report proper mbr partition table, gdisk also reports broken gpt header, backup header problems, etc. pp.

     

    When i tried to fix up the disk images with zeroe'd space and ONLY mbr, it won't boot either, so IMHO no confusion.

    When i fixed up the images to ONLY have GUID partition table, the images boot fine.

     

    Note that radxa's own images do come with GUID partition table.

     

    My rockpi4a is v1.4, and i am not 100% sure that it didn't work from the start, but maybe there was some upgrade of bootloader/sppi, or whatever, when i was playing around with the radxa debian images, so one time when i tried to start using armian, the images didn't boot anymore.

     

    No idea how to further troubleshoot, e.g.: bootloader version or the like. Not sure the armbianmonitor output is of any help.

     

    http://ix.io/2bgj

     

    Btw: Why does armbian partition start at sector 32768 instead of usual sector 2048 ? I zeroed out the first 32768 sectors, and that didn't hurt the ability to boot, so doesn't seem as if there is any hidden bootstrap code. Instead, i was positively surprised i didn't need any magic boot code (like on x86), but just a clean GUID with the ext4 armbian partition to boot.

  13. In my case the zram problem happens after every reboot.

    RockPi4A/1Gbyte/32GB emmc running Armbian_20.02.0-rc1_Rockpi-4b_bionic_legacy_4.4.210_desktop.7z

     

    root@rockpi:~# armbianmonitor -u
    System diagnosis information will now be uploaded to cat: /var/log/armbian-hardware-monitor.log: Input/output error
    gzip: /var/log/armbian-hardware-monitor.log.1.gz: No such file or directory
    server closed the connection unexpectedly
            This probably means the server terminated abnormally
            before or while processing the request.
    Please post the URL in the forum where you've been asked for.

    root@rockpi:~# df -k /var/log
    Filesystem     1K-blocks  Used Available Use% Mounted on
    /dev/zram0         49584  4324     41676  10% /var/log
     

    Console:

    [35959.400713] EXT4-fs error (device zram0): ext4_find_extent:916: inode #25: comm rs:main Q:R)
    [35959.410268] EXT4-fs error (device zram0): ext4_find_extent:916: inode #25: comm rs:main Q:R)
    [35959.421957] EXT4-fs error (device zram0): ext4_ext_remove_space:2999: inode #25: comm rs:ma)
    [35959.432859] EXT4-fs error (device zram0) in ext4_ext_truncate:4688: Filesystem failed CRC
    ...

     

    32GB eMMC with >> 50% unused should have a lot of spare cells to live long even if i was not using zram ???

  14. I now have a RockPi4a running Armbian_20.02.0-rc1_Rockpi-4b_bionic_legacy_4.4.210_desktop from eMMC.

     

    Now i wanted to see how i most easily can experiment with newer distributions, such as 5.x.

     

    The radxa debian images for rockpi4 use a lot of partitions and it was quite easy to reformat the eMMC to have two system partitions, install different linux versions into them, and then configure the boot script to allow booting from different partitions/kernels via serial console and there selecting the desired kernel.

     

    In Armbian,  it seems booting uses the boot.cmd script to boot the kernel. Is there a simple example of the boot script with a menu to select boot kernel ? If not, where is this scripting language documented ?

  15. 1 hour ago, martinayotte said:

    Yes ! It is defaulted to 1 i /boot/armbianEnv.txt ...

    Indeed. Thanks. See below.

     

    Seems to hang in a similar place as my self compiled debian kernel, after (in?) system clock setting.

     

    But at least it seems as if i i can forget to understand the bootstrap process because it seems i should be able to just boot different kernels, debian/armbian. If the 5.x armbian kernel would not like the 4.4 filesystem, i could create another partition as a second root partition. 

     

    On my running 4.4 debian, this is what follows after clock setting:

     

    [    2.928947] I : [File] : drivers/gpu/arm/mali400/mali/linux/mali_kernel_linux.c; [Line] : 417; [Func] : mali_module_enit(); svn_rev_string_from_arm of this mali_ko is '', rk_ko_ver is '5', built at '11:59:48', on 'Dec 14 2019'.

    [    2.931490] Mali: Mali device driver loaded

     

    GPU initialization does of course look like a potentially difficult piece. Any kernel option to disable GPU ?

     

     

    bootlog.armbian5.4.test3.txt

  16. 15 hours ago, Igor said:

    It doesn't convince me :P We just save you a big chunk of it. You would waste weeks without guidance and hints.

     

    Most likely, yes, but me trying to tinker with my toys is something i can do in the random spare time i have. Being maintainer requires small but more predictable longer term cycle allocation which is the issue.

     

    I still have a banana to offer to the community :P  

  17. Thanks chwe for all the info. 

     

    Alas, my Rock PI 4 setup isn't even at home, so i have to first figure out how i can continue troubleshooting given how it doesn't seem to be possible to do without physcial access. Aka: will probably want to see if i can get netboot to work, because then i could safely overwrite uSD/eMMC from remote.

  18. Haha, nice pitch for maintainer positions. Alas, not enough time, and no spare new hardware to play around with.

     

    I can contribute the predecessor HW to my rock pi 4 + miniPCI card, which is a banana pi M1 and a SATA port multiplier, but that is such old hardware, and i think almost not sold anymore (and Rock PI 4 + miniPCIE would be so much better if i'd get the one problem fixed).

    And i guess one of your maintainers will already have a banana pi m1 given how you list it as supported.

  19. 9 minutes ago, Igor said:


    Study manual.

     


    Boot still starts on eMMC where they implement a hack that it loads kernel from elsewhere first if exists. We did the same with MiQi back in the days.

     

     

    Yes if there is support for network card in the u-boot that resist on SPI. Start R&D to find out if that is true and implement that to build script that others will benefit from your work. I hope you don't expect we will do that for you?

     

    Moving to DEV zone.

     

    Thanks!

     

    Wrt. "study manuals" - yes, thats what i am trying to do, but there is no good description of the boot process, especially priority of diffeent media over each other on the radxa wiki, or if there is, i have not found it. But once i understand it, i am happy to improve the text.

     

    The rockchip URL provides a lot of detail, but i would not even know without additional documentation from another place or RTFS on my behalf whether the rock pi 4 uses the red or the blue path.

     

    But the explanation you provided about some form of hack might be an explanation of the problem i am seeing: If my 4.4 debian eMMC system actually boots some initial boot stage(s) from eMMC, and one of those stages then looks at the uSD and continues to boot from there, then this could explain why  this might work with a 4.4 armbian in the uSD slot, but not a 5.x in the uSD slot.

     

    Which stage has this hack that looks first at uSD ? And do you have any idea if it could be that that hack could only continue to boot then from uSD a 4.4 system, but maybe not a 5.x one ?

     

    Btw: The note you said you added to the rock pi 4 page may not be correct. Even if the problem is not only because of me also having an eMMC card, its probably more an IMG issue and not a kernel issue (unless the kenel is booting but i can not see it on the console because its not correctly supporting the console).

     

     

×
×
  • Create New...