Jump to content

Recommended Posts

Posted

I've tried searching the forums for info on the Pine H64 Model B, but all the information is rather outdated, so I have some questions:

  • Is this board supported by the images on the Pine H64 page which show a Model A board? (There was mention they work but without ethernet support.)
  • Has ethernet support been fixed in the Pine H64 images for Model B?
  • Are nightly builds still disabled for these boards?

 

Posted
7 minutes ago, Neko May said:

Is this board supported by the images on the Pine H64 page which show a Model A board?

 

I think no. Nobody is specifically take care over model B

8 minutes ago, Neko May said:

Has ethernet support been fixed in the Pine H64 images for Model B?


I only test on model A. No idea.

 

9 minutes ago, Neko May said:

Are nightly builds still disabled for these boards?


Yes, until someone sent a PR with changes.
https://github.com/armbian/build/blob/master/config/targets.conf#L521-L525

Posted

Alright. I have a Model B on the way, I can try out the latest images when it gets here (which will probably be late December to early January) and report back.

Posted

I did a little research, and as far as I can tell, the Model A was discontinued in favor of the Model B; Nobody offers the Model A for sale, and numerous sources mention that it has been superseded.

 

I have not yet determined differences beyond the Model B including WiFi/Bluetooth and eliminating the MiniPCIe slot (likely due to the unusable implementation in the H6) as well as the much more obvious change in form factor.

 

(My board has not arrived yet, but I will have more information when it does.)

Posted
On 12/20/2019 at 8:14 AM, Neko May said:

My board has not arrived yet, but I will have more information when it does


 I added support and images for model B, but I don't own this hardware ...  https://dl.armbian.com/pineh64-b/

 

@TonyMac32 You got this board? You have gears and time to make a hires photo?

Posted
On 12/25/2019 at 11:48 AM, Igor said:

You got this board? You have gears and time to make a hires photo?

 

Sorry for the delay, I got locked out for a bit.  :rolleyes:  Let me know what you think of it, it's uploaded/attached.

Posted (edited)

Tested the Buster Desktop image built 25-12-2019, it stops at "Begin: Waiting for root file system" and sits there blinking the cursor forever when using the eMMC module. With SD Card it's fine.

 

Attempted to boot the AOSC image on the PINE64 wiki which is specified to be for "eMMC Boot" and it gets to a certain point before throwing a data error on the eMMC, complaining and disabling IRQ 96 then hanging forever in a kworker thread related to the eMMC.

Edited by Neko May
Posted

I can confirm that current image starts well on sd card with the 3G version (server image + installation of desktop with armbian-config).

Posted

I have build myself Ubuntu 18.04 version for that board. Kernel 5.4.6. ( 19.11.5 )

But eth0 does not work. The same situation as 

But i have img with 5.77 Armbian ubuntu 18.04 kernel 5.0.5 and that is working.

It is strange. Kernel 5.0.5 has no problem and 5.4.6 not.

Settings static IP help nothing... eth0 is not recognize.

 

By the way - Happy New Year 2020 to Armbian Team 

Posted
13 minutes ago, constantius said:

The same situation as

What do you mean ?

Is your issue exactly the same as described in the thread, meaning ETH0 is working at cold boot but not when rebooted ?

 

Posted
15 minutes ago, constantius said:

yes etho is disabled after reboot and even earlier before reboot when i tried do something what need internet - for example do command ping

Are you sure ? When you say "even earlier", do you mean just after during "cold boot" you get problem with ping ?

Maybe it is not the same issue ...

Try the following : "systemctl disable NetworkManager" and use plain "old school" /etc/network/interfaces to do your network setup.

Posted
21 minutes ago, martinayotte said:

Try the following : "systemctl disable NetworkManager" and use plain "old school" /etc/network/interfaces to do your network setup.

This does not work.

I think you are right... Connection sometimes ends earlier. that maybe differenf issue. I have img build earlier myself with 5.05 kernel Armbian 5.77 - that works

Posted

I have an update to the eMMC situation:

- Linux will hang trying to boot off the eMMC. If booted from SD, attempts to access the eMMC will cause the process to hang.

- NetBSD has been tested to boot off of SD, and has no trouble accessing the eMMC.

 

Looks like a Linux kernel bug.

Posted
1 minute ago, Neko May said:

and has no trouble accessing the eMMC.


Accessing is one thing. Can it boot from it?

Posted
57 minutes ago, Igor said:


Accessing is one thing. Can it boot from it?

I'll give it a try tomorrow and give an update.

Posted

NetBSD successfully boots from eMMC using the same image as for SD.

 

(I should clarify, Armbian boots from either; kernel is entered, initrd is laded and setup begins, but it hangs up trying to access the eMMC to mount the root filesystem, or if you boot from SD, it gets to multiuser but processes that try to access it will hang. There's something wrong in Linux with accessing the eMMC on this board/SoC. (I have another H6 board coming maybe within a month so I'll be able to test eMMC on there when it arrives.))

Posted

maybe relevant: this is a patch i need on h6 tv boxes to get stable emmc access ... not sure if it is in armbian already - it originally comes from @megi or @Icenowy i think ...

 

best wishes and good luck - hexdump

--- drivers/mmc/host/sunxi-mmc.c	2019-08-22 20:06:32.487082136 +0200
+++ drivers/mmc/host/sunxi-mmc.c	2019-08-22 20:08:20.415078693 +0200
@@ -1394,15 +1394,17 @@ static int sunxi_mmc_probe(struct platfo
 				  MMC_CAP_ERASE | MMC_CAP_SDIO_IRQ;
 
 	/*
-	 * Some H5 devices do not have signal traces precise enough to
-	 * use HS DDR mode for their eMMC chips.
+	 * Some H5 and H6 devices do not have signal traces precise
+	 * enough to use HS DDR mode for their eMMC chips.
 	 *
 	 * We still enable HS DDR modes for all the other controller
 	 * variants that support them.
 	 */
 	if ((host->cfg->clk_delays || host->use_new_timings) &&
 	    !of_device_is_compatible(pdev->dev.of_node,
-				     "allwinner,sun50i-h5-emmc"))
+				     "allwinner,sun50i-h5-emmc") &&
+	    !of_device_is_compatible(pdev->dev.of_node,
+		    		     "allwinner,sun50i-h6-emmc"))
 		mmc->caps      |= MMC_CAP_1_8V_DDR | MMC_CAP_3_3V_DDR;
 
 	ret = mmc_of_parse(mmc);

 

Posted
18 hours ago, hexdump said:

it originally comes from @megi or @Icenowy i think ...

What is strange is that Armbian is using @megi branches and this patch isn't present there ...

 

What is also strange is that my PineH64 doesn't have any issue with the eMMC.

Posted

Also, the board loads U-Boot, the kernel and the initrd just fine, and NetBSD has no trouble at all with the eMMC. This isn't a board problem. I'll be able to test on an Orange Pi 3 hopefully within a month, but I'm not convinced this has anything to do with the boards.

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines