Orange Pi3 lts

[Kamileon]

Yes, but I can hookup to a monitor. I was counting on ssh but it wont get DHCP address from my router

[Ukhellfire]

1 minute ago, Kamileon said:

Yes, but I can hookup to a monitor. I was counting on ssh but it wont get DHCP address from my router

Is the ethernet actually working? I saw something in my dmesg about ethernet. I didn't plug it in though.

Have you tried with a monitor plugged in? I've got a feeling you might see something.

As mine boots as soon as the green light shows. I'm hooked into a monitor. And I then go through the create locales bit, then it's sets up my desktop? 

[Kamileon]

8 minutes ago, Ukhellfire said:

Is the ethernet actually working?

Don't know about that but this is interesting:

https://nextcloud.lodz.webredirect.org/s/8KLjGABaybesQTD

[Ukhellfire]

3 minutes ago, Kamileon said:

Don't know about that but this is interesting:

https://nextcloud.lodz.webredirect.org/s/8KLjGABaybesQTD

Right OK. You've dropped to a shell. Which means rootfs is there. 

I like the way it's suggesting rootdelay. Maybe I try upping it? It's set to 5 seconds at the moment.

I'll adjust this in the dts files and see what happens! Also going to add in the actual path to root in the bootargs see if it makes a difference. Aswell as a couple of other adjustments. 

[Kamileon]

2 hours ago, Ukhellfire said:

I like the way it's suggesting rootdelay. Maybe I try upping it? It's set to 5 seconds at the moment.

Worth a try

[Ukhellfire]

7 hours ago, Kamileon said:

Worth a try

Well... there's another img in the folder. I'm adding dated folders at the moment until I start removing.

I've upped the rootdelay to 10. I did a search through orangepis github, and the results I found were all set to 10. So I went for that! Haha!

I've also told it where to look for the rootfs with the root=/dev/mmcblk0p1 flag. Not sure if this will make a difference or not. Still, I do think things are just taking that little bit to long and uboot doesn't like it. Might be wrong...

 

https://drive.google.com/drive/folders/16UHmZsGD4qv7HqY5pPtZcQZ1WeEBDFA8

[Kamileon]

Tested new image, unfortunately still dropping to a shell, so there must be something more that blocks

[orangepifan]

On 3/16/2022 at 8:28 PM, Ukhellfire said:

Well... there's another img in the folder. I'm adding dated folders at the moment until I start removing.

I've upped the rootdelay to 10. I did a search through orangepis github, and the results I found were all set to 10. So I went for that! Haha!

I've also told it where to look for the rootfs with the root=/dev/mmcblk0p1 flag. Not sure if this will make a difference or not. Still, I do think things are just taking that little bit to long and uboot doesn't like it. Might be wrong...

 

https://drive.google.com/drive/folders/16UHmZsGD4qv7HqY5pPtZcQZ1WeEBDFA8

Tried this image, getting to busybox because can't find volume with UUID=xxxxx. So, it seems to at least try to boot, but then can't find the root partition later... very odd.

[amaethon]

I tried the image too and have the same problem. I can't add more than that, but I am able to successfully boot the images provided by organgepi.org using the same SD card.

[Ukhellfire]

11 hours ago, orangepifan said:

Tried this image, getting to busybox because can't find volume with UUID=xxxxx. So, it seems to at least try to boot, but then can't find the root partition later... very odd.

This is exactly the problem. 

I'm trying furiously to find out what's causing this though. And I'm coming up stumped! 

I'm currently trying to parse the correct path to root. But for some reason, it's just not having it. 

I can't use the mmcblk path anymore, as this isn't used, and hasn't been used since the 4.x kernel days. 

 

Wondering now if anyone else has any ideas? Seen this before? Can point me in the right direction? @Werner 

Obviously a uboot log has been posted previously here. I believe that would still apply? 

[Werner]

No clue, sorry.

[Ukhellfire]

4 minutes ago, Werner said:

No clue, sorry.

That's fair enough! Any idea who could help? 

I'm currently comparing orangepis uboot sunxi-common.h and armbians. I think it may be something I  there...

[orangepifan]

1 hour ago, Ukhellfire said:

That's fair enough! Any idea who could help? 

I'm currently comparing orangepis uboot sunxi-common.h and armbians. I think it may be something I  there...

Kernel development is over my head and I'm not familiar enough with how the boot process works on x86, never mind on ARM. Is it possible uBoot has all the necessary support to find the storage devices, but somehow the kernel doesn't? Are there perhaps storage devices that require a kernel to load (SD card, etc).

 

Perhaps this has a possible interaction: https://archlinuxarm.org/forum/viewtopic.php?f=45&t=14517

I note they add an extra part of the arguments "PARTUUID". Total shot in the dark here!

[Ukhellfire]

16 hours ago, orangepifan said:

Kernel development is over my head and I'm not familiar enough with how the boot process works on x86, never mind on ARM. Is it possible uBoot has all the necessary support to find the storage devices, but somehow the kernel doesn't? Are there perhaps storage devices that require a kernel to load (SD card, etc).

 

Perhaps this has a possible interaction: https://archlinuxarm.org/forum/viewtopic.php?f=45&t=14517

I note they add an extra part of the arguments "PARTUUID". Total shot in the dark here!

I thought I had a pretty good understanding of it! Apparently not! 

Although, I think it's the uboot side of things letting me down! Haha!

 

@jernej this is the thread. As you can see above, we're not able to boot this board, as the root fs for some reason isn't booting properly, and is hanging at the "starting kernel" stage, and then dropping to the initramfs shell. 

Was wondering if there qas any direction you could advise going? Or if you've come across this before? Or anyone that has? 

Any help would be greatly appreciated! And I would owe you big time! Haha!

 

As you can see, I'm trying to bring the board up, but it's not going quite as planned! Haha! 

[jernej]

There is no reason why standard method wouldn't work on OPi 3 LTS. It's possible that something in DT file isn't set correctly, although quick comparison doesn't show anything useful. Show me output of dmesg, maybe there is something useful there.

[Ukhellfire]

5 minutes ago, jernej said:

There is no reason why standard method wouldn't work on OPi 3 LTS. It's possible that something in DT file isn't set correctly, although quick comparison doesn't show anything useful. Show me output of dmesg, maybe there is something useful there.

That's all the sort of thing I've been checking...

How would I go about getting the dmesg if it doesn't boot?

[jernej]

19 minutes ago, Ukhellfire said:

How would I go about getting the dmesg if it doesn't boot?

Initiramfs shell should support dmesg command. If not, remove "quiet" from kernel arguments and you'll get basically the same output on serial.

[Ukhellfire]

Just now, jernej said:

Initiramfs shell should support dmesg command. If not, remove "quiet" from kernel arguments and you'll get basically the same output on serial.

Ah OK thanks. 

This is where I can't go much further, unless I can get anyone else here to help out?

@Kamileon

@Rockford the Roe

@orangepifan???

It's not detecting my usb keyboard on the initramfs shell. And I don't have a serial adaptor (yet, about to jump on amazon!)

 

[jernej]

24 minutes ago, Ukhellfire said:

It's not detecting my usb keyboard on the initramfs shell.

If you have an option to build custom kernel, you can mark usb keyboard driver as =y and it will be included in kernel directly, so it should work from initramfs shell too.

[Ukhellfire]

On 3/19/2022 at 12:53 PM, jernej said:

If you have an option to build custom kernel, you can mark usb keyboard driver as =y and it will be included in kernel directly, so it should work from initramfs shell too.

I shall give this a go! Thank you! 

 

Right.

I have no idea how this works. 

I have just booted a build from a couple of days ago.

All i did was reflash the card, and put it in and turn it on.

 

@jernej

I had red errors on boot by the looks of it, loading kernel modules apparently.

So what ive done, is grab a dmesg from that...? not sure if it will show anything. going to scan through it. 

ill post a link to it.

 

https://drive.google.com/file/d/1fjKfERnbD-z2f2C6Ia_UOBMygxzAzmiD/view?usp=sharing

 

fingers crossed this helps a bit!

[jernej]

@Ukhellfireboot looks good, except when loading modules. I haven't seen anything like that. Did you by any chance build kernel and modules separately, possibly with different compiler/settings? This is more or less the only reason for such issues.

[Ukhellfire]

15 minutes ago, jernej said:

@Ukhellfireboot looks good, except when loading modules. I haven't seen anything like that. Did you by any chance build kernel and modules separately, possibly with different compiler/settings? This is more or less the only reason for such issues.

No it's all just the normal armbian build. 

Well that's the thing. I seem to be the only person able to boot this? 

And that's after 2/3 power cycles etc...

So I'm back to the dmesg from the shell that the builds are dropping to normally. I can now use initramfs to get a dmesg, but how do I send it to file? Its not going anywhere with the normal command? Am I going to have to start mounting things? Or am I missing something? 

[jernej]

11 minutes ago, Ukhellfire said:

I can now use initramfs to get a dmesg, but how do I send it to file?

How do you access initramfs console? Via connected HDMI monitor? If so, then take a photo of each dmesg page Anyway, serial is basic requirement for debugging boot issues.

 

Anyway, if it's possible to boot sometimes, but not otherwise, it's possible that there is timing issue, insufficient voltage of some regulator or too high frequency. Unfortunately, all of these things are hard to debug, especially remote.

[Ukhellfire]

@jernej

Well so far luck is not on my side.

I hit the dmesg command and get pages fly up. 

I hit shift+page up, but can only see the last like, 2 pages... 

As for the serial adaptor, I have one on order. It should be with me within the next couple of days... i used to have one, but lent it out, and never got it back! Wasnt so worried and didn't think about it for this. 

Didn't think I'd be needing one! 

[Rockford the Roe]

3 minutes ago, Ukhellfire said:

@jernej

 

As for the serial adaptor, I have one on order. It should be with me within the next couple of days... i used to have one, but lent it out, and never got it back! Wasnt so worried and didn't think about it for this. 

Didn't think I'd be needing one!

I'm also getting one for myself. However, it's being shipped from China and they usually take a month to get here to the US.

[Ukhellfire]

 

2 minutes ago, Rockford the Roe said:

I'm also getting one for myself. However, it's being shipped from China and they usually take a month to get here to the US.

I'm going to order from amazon. Should be here next day.

 

Also, already found one error.

Unknown hardware address the pmic@36

https://github.com/afaulkner420/Linux-Mainline-5.15y/blob/main/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3-lts.dts#L234

This should be pmic@745 or something I believe... 

 

I believe pmic@36 is for i2c, but rsb is being used which should be pmic@745

See here

https://github.com/afaulkner420/Linux-Mainline-5.15y/commit/da7543d5f4ff07e928c7ee9dd7ff6d43a9f290de#diff-a4a19679112dc0d3c1b1a94e31bd63da1e10f0614ef50ea9e09bb8d650ebc1b6R231

[jernej]

@Ukhellfire if that is the DT file you're using, then yes, regulator address is wrong. You see, it can work via I2C bus, where it has address 0x36 or via RSB bus, where it has address 0x745. In DT file you mentioned, it's connected to RSB bus, so address is wrong. Change @36 to @745 and reg = <0x36>; to reg = <0x745>; and all regulator related issues should go away.

[Ukhellfire]

Just incase this helps anyone, I've just discovered I should be able to use my old arduino mega2569 as a serial to usb adaptor...

 

I shall try this out later/tomorrow and report back! 

[jernej]

4 minutes ago, Ukhellfire said:

I've just discovered I should be able to use my old arduino mega2569 as a serial to usb adaptor...

Yes, you can, but be careful to work at 3.3 V, otherwise you'll damage H6 chip.

[Ukhellfire]

On 3/19/2022 at 10:44 PM, jernej said:

Yes, you can, but be careful to work at 3.3 V, otherwise you'll damage H6 chip.

Would it not just be plugged into mains as normal? Then just the tx/rx/gnd as normal? 

 

On 3/19/2022 at 10:31 PM, jernej said:

@Ukhellfire if that is the DT file you're using, then yes, regulator address is wrong. You see, it can work via I2C bus, where it has address 0x36 or via RSB bus, where it has address 0x745. In DT file you mentioned, it's connected to RSB bus, so address is wrong. Change @36 to @745 and reg = <0x36>; to reg = <0x745>; and all regulator related issues should go away.

And yeah that's what I'm about to do. I changed it without really knowing. Read up on it, and meant to change it back. But forgot. 

In the dts file from orangepi, it uses i2c, I ported to rsb from the orange pi 3 dts. Should I go back to what was in the original from orange pi? Or is rsb better to use? I've read rsb is better?