Jump to content

Recommended Posts

Posted

The newest revision does not boot from current SD images.  I'm working to debug why.  If anyone else has a board and can test it out, let me know.  The eMMC will boot, no problem, so it's just the SD itself.

 

Model: Pine64 Rock64
DRAM:  1022 MiB
MMC:   rksdmmc@ff520000: 0, rksdmmc@ff500000: 1
SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environment

In:    serial@ff130000
Out:   serial@ff130000
Err:   serial@ff130000
Model: Pine64 Rock64
misc_init_r
cpuid=55524b50303930343200000000051f1a
serial=f55c6806c317581
Net:   eth0: ethernet@ff540000
Hit any key to stop autoboot:  0
Card did not respond to voltage select!
mmc_init: -95, time 9
switch to partitions #0, OK
mmc1 is current device
** No partition table - mmc 1 **
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   Core Release: 3.10a
USB3:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 2 USB Device(s) found
scanning bus 2 for devices... 2 USB Device(s) found
scanning bus 3 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

Device 0: unknown device
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT 

Ideally getting old an new to boot would be ideal, @Igor this might mean a fragmentation for this board though, like having a V2 and older and a V3 and newer build if we can't make them all play nice with one bootloader.

Posted
  On 3/4/2019 at 3:05 AM, TonyMac32 said:

this might mean a fragmentation for this board though, like having a V2 and older and a V3 and newer build if we can't make them all play nice with one bootloader.

Expand  


OMG :o I hope it won't be needed.

Posted
  On 3/4/2019 at 5:23 AM, Igor said:

OMG :o I hope it won't be needed.

Expand  

 

Agreed, but I'm having flashbacks to the MiQi boot order vs. the Tinker Board.  I should be able to look at it more fully tomorrow.

Posted

My Rock64 is using this build since 6 weeks :

Linux rock64 4.20.0-rockchip64 #5.72 SMP Thu Jan 17 16:15:05 EST 2019 aarch64 GNU/Linux

 

EDIT : Now building Ayufan 4.20.13 ... will see !

EDIT2 : My Rock64 is now updated with 4.20.13 without any issues ...

Posted
  On 3/4/2019 at 2:22 PM, martinayotte said:

My Rock64 is using this build since 6 weeks :

Expand  

A rev 3 board?  My Rev 1 boots no problem all of our images.  It's the new one I just got that refuses.  How much RAM does yours have, this looks like a 1GB model, maybe it's trying to load something out of the memory space.

Posted
  On 3/4/2019 at 6:34 PM, martinayotte said:

Is it refuse to boot even without eMMC plugged ?

Expand  

Yes.  That's the issue here is with the brand new revision, eMMC unplugged, plugged, etc, doesn't matter.  U-boot loads, faults out to PXE and gives up.  I had a thought to verify the U-boot is indeed the one from the SD, I don't know if the SPI is preloaded or not...

Posted
  On 3/4/2019 at 7:02 PM, TonyMac32 said:

I don't know if the SPI is preloaded or not...

Expand  

Right, that can be an issue ...

If you stop the u-boot with <spacebar>, what "mmc list" is reporting ?

Then "mmc dev" followed with "mmc info" , finally "ls mmc X" ?

Posted

:lol: you'll have to wait on those results, I'm at the day job wrestling lightning bolts and B-fields, choking on magic smoke.

Posted

How's the Rev 3 of the ROCK64 going?  How did you manage to get it as the website doesn't seem to show whether its rev2 or 3 that you get....  Realise there are more powerful boards out there but don't need some power hungry board for my needs, though the Odroid N2 looks tempting and low power too.

Posted

Hi @Thewonderer, I have dev samples of a few boards, it's one of the ways we work with vendors that show interest.  My other Rock64 is a pre-V1, so I wanted to make sure I had something representative moving forward.  I've had some personal projects going, and @martinayotte moved so much around on these boards I decided to stay out of the way.  :lol: Taking a look at the u-boot configs and device trees tonight to see if I can find a difference, the Renegade image got to the point of loading kernel (obviously didn't get past that with the differences in DTS's) on the Rock64 3.0 while the Rock64 V1/2 image would not, telling me there's no hardware issue.

 

@martinayotte did you try to boot Renegade with newer u-boot?  I can't remember if you have one or not.

Posted

They've just sent me a v2 even though I requested v3. They said v3 not released on website and I can return. I got the impression from Twitter that they had v3 ready.

 

Thanks for doing work on v3 bring up in armbian!

Posted
  On 3/20/2019 at 3:00 AM, TonyMac32 said:

Hi @Thewonderer, I have dev samples of a few boards, it's one of the ways we work with vendors that show interest.  My other Rock64 is a pre-V1, so I wanted to make sure I had something representative moving forward.  I've had some personal projects going, and @martinayotte moved so much around on these boards I decided to stay out of the way.  :lol: Taking a look at the u-boot configs and device trees tonight to see if I can find a difference, the Renegade image got to the point of loading kernel (obviously didn't get past that with the differences in DTS's) on the Rock64 3.0 while the Rock64 V1/2 image would not, telling me there's no hardware issue.

 

@martinayotte did you try to boot Renegade with newer u-boot?  I can't remember if you have one or not.

Expand  

 

Does the SD card appear later in the boot process, when you boot from eMMC?

Posted
  On 3/20/2019 at 1:36 PM, martinayotte said:

not so much ... ;)

Expand  

 

Mmhmm.  :lol:

 

my V1 has no problems with our u-boot, it is fine from eMMC and from SD.  The V3 is fine from eMMC if I 'transplant' it from the V1 to the V3.  SD using our u-boot recipe somewhere goes wrong on V3, so I need to debug

Posted (edited)
  On 3/4/2019 at 7:06 PM, martinayotte said:

If you stop the u-boot with <spacebar>, what "mmc list" is reporting ?

Then "mmc dev" followed with "mmc info" , finally "ls mmc X" ? 

Expand  

 

Sorry I didn't get back to you, but here goes:

=> mmc list
rksdmmc@ff520000: 0
rksdmmc@ff500000: 1 (SD)
=> mmc info
Device: rksdmmc@ff500000
Manufacturer ID: 3
OEM: 5344
Name: SL16G
Tran Speed: 50000000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 14.8 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
=> ls mmc 1
 ** ext4fs_devread read error - block
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **

Now, to be completely clear, that SD card boots perfectly on a revision 1 board.  I was talking to Pine, I think I might have to reach out again.

 

Interestingly, if I stuff my Renegade SD into the Rock64 I get this:

  Reveal hidden contents

...Where it of course freezes because it is not a Renegade and they are different enough for that to be a problem.

 

What options and hardware combo would wreck reading the SD card?  *head explodes*

 

Edited by Tido
added spoiler
Posted

I don't think this has anything to do with the drive strength, I can scan different SD's with no issue, reading the mfg info/type/size/etc. But it won't recognize the filesystem in any of them. (Tried 6 different ones)

Sent from my Pixel using Tapatalk

Posted

This is from Rock64 Rev 3.

  Reveal hidden contents
=> version
U-Boot 2017.09-armbian (Mar 20 2019 - 22:48:31 -0400)

aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011
GNU ld (Linaro_Binutils-2017.11) 2.28.2.20170706

=> ls mmc 1:1
** No partition table - mmc 1 **
=> ls mmc 1:0
 ** ext4fs_devread read error - block
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
=>

Pulling the exact same card out of the Rev 3 and stopping boot on the Rev 1:

  Reveal hidden contents
=> version
U-Boot 2017.09-armbian (Mar 20 2019 - 22:48:31 -0400)

aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011
GNU ld (Linaro_Binutils-2017.11) 2.28.2.20170706

=> ls mmc 1:1
<DIR>       4096 .
<DIR>       4096 ..
<DIR>      16384 lost+found
<DIR>       4096 bin
<DIR>       4096 boot
<DIR>       4096 dev
<DIR>       4096 etc
<DIR>       4096 home
<DIR>       4096 lib
<DIR>       4096 media
<DIR>       4096 mnt
<DIR>       4096 opt
<DIR>       4096 proc
<DIR>       4096 root
<DIR>       4096 run
<DIR>       4096 sbin
<DIR>       4096 selinux
<DIR>       4096 srv
<DIR>       4096 sys
<DIR>       4096 tmp
<DIR>       4096 usr
<DIR>       4096 var
=> ls mmc 1:0
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
=>

 

Posted

I'll be able to check later, but the SD is ext4, and I am moving the same physical SD between the two revisions of the board without any other changes. I did a lot of other tests on my own earlier on, MMC 0 is not present (and is not installed, so ok).

Sent from my Pixel using Tapatalk

Posted

Perhaps the answer is in this quote.

 

New Rock64 Revision 3 features include support for Power over Ethernet, a Real Time Clock, support for high-speed microSD cards, and improved PI2 GPIO compatibility.

Posted
  On 3/23/2019 at 12:09 PM, balbes150 said:

Perhaps the answer is in this quote. 

 

New Rock64 Revision 3 features include support for Power over Ethernet, a Real Time Clock, support for high-speed microSD cards, and improved PI2 GPIO compatibility.

Expand  

 

Yes, I had considered this but had (probably wrongly) thought that the uboot code wasn't using it since it didn't die on boot with the Rev 1 that it wasn't trying to switch regulators.  (could be trying but nothing is changing, now the gpio is wrong? Schematic searching...)

Posted

The issue is that GPIO0_D6 (SDMMC0_PWREN) is left floating by current Linux devicetree configurations, but needs to be set to high or low in order to select an appropriate SDCard voltage. Armbian will need to be updated to set this pin corrently.

 

To get the current non-updated version of Arbmian running on a v3 (I've tested this), you can solder a connection between test pad 2302 and 3.3v to revert your Rev3 board's SD-Card slot to Rev2 behavior, which should work with all cards.
If you have a UHS-capable MicroSD card, you can solder a connection between test pad 2303 and ground to force the slot into UHS mode.

The test pad can be located on the back of the PCB, near the center. I've highlighted it in this drawing, in red: https://i.imgur.com/F9BCSkj.png

Posted

No need for hardware hacking, I will try to address this tonight, it is in my open items. :-)

Sent from my Pixel using Tapatalk

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

Important Information

Terms of Use - Privacy Policy - Guidelines