Hello, 

 

I search the Documentation about LED and Its blinking status. 

 

My Board does not anymore boot, Green LED is on (not blinking) red LED is blinking regulary

CPU gets very hot and no Screen output.

 

I use the latest armbian image using the following link

 

https://dl.armbian.com/rockpi-4b/Ubuntu_bionic_default_desktop.7z

 

Does anyone have a hint for me

 

Many Thanks

 

Roman

The best way to troubleshoot such issues is to connect a USB-TTL Serial dongle to Serial Debug port header and look at the boot log process ...

 

52 minutes ago, SecureXperts said:

My Board does not anymore boot, Green LED is on (not blinking) red LED is blinking regulary

 that should be the normal behavior.. As far as I know, there's no way to toggle green.. Tried it once and failed.. But without bootlog from serial.. there's no way to help you.

 

 

btw... the title is a bit... --> well I fixed it for you..

 

Edit:

https://github.com/armbian/build/blob/de327f566bb747fb401f75b10ef77e7d614af2c0/patch/kernel/rockchip64-default/add-rockpi4b.patch#L309-L323

 

should explain the LED behavior, but at least on mainline only red could be triggered.. Green was always on..

54 minutes ago, SecureXperts said:

My Board does not anymore boot, Green LED is on (not blinking) red LED is blinking regulary

CPU gets very hot and no Screen output.

 

I use the latest armbian image using the following link

 

https://dl.armbian.com/rockpi-4b/Ubuntu_bionic_default_desktop.7z

 

Does anyone have a hint for me

Hi. Did you try an image from Radxa themself? Is it with eMMC or sd-card?
https://wiki.radxa.com/Rockpi4/downloads

@chwe I build an RockPi4 image today, and it also didn't boot. I tried 3 different eMMC modules. Then installed the Armbian from Radxa on it and this works. But there's no zram there.
I'll see if I can find an sd-card to try it with that. Then I'll try building another image with dev kernel instead.

I got my big heatsink for it today. So I want to set it up as good as possible. But I think I'm gonna stick with the Ubuntu Server from Radxa for the moment.
Cheers.

1 minute ago, NicoD said:

@chwe I build an RockPi4 image today, and it also didn't boot. I tried 3 different eMMC modules. Then installed the Armbian from Radxa on it and this works. But there's no zram there.
I'll see if I can find an sd-card to try it with that. Then I'll try building another image with dev kernel instead.

WIP so things like that are expected.. Provide a bootlog and I'll have a look into it..

 

[small to medium rant]

If it's a Raxda produced 'Armbian' things might not work and I'll not fix it.. They decided to use their own 4.4 kernel fork and I'm not willing to look into it. If they want a more stable 4.4 based armbian Image they should contribute to Armbians 4.4 Kernel (basically @ayufan one with some patches). And not something like this:

https://github.com/brian541/build

We won't maintain a third RK3399 bsp kernel only cause there's a new board out which throws us a bunch of errors with ayufans kernel..

 

That's where their armbian previews came from... The whole device tree looks like a fire and forget push.. e.g.

 

https://github.com/radxa/kernel/blob/155a65a72b20b477663218ce47fd9130579ab375/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts#L645-L707

doesn't make sense at all.. The CSI populated on the board is a 2 lane 'RPi alike one' whereas ov13850 is a 13mp camera normally connected via 4lane mipi csi.. Looks like some leftover from a firefly or so.. Even then, it's on a different i2c bus which also looks fishy..

 

https://github.com/radxa/kernel/blob/155a65a72b20b477663218ce47fd9130579ab375/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts#L271-L286

didn't work.. At least only one LED could be triggered.. or there's a third led somewhere which I didn't spot.. Unfortunately there aren't public available schematics to get a clue how things are soldered together here..

 

https://github.com/radxa/kernel/blob/155a65a72b20b477663218ce47fd9130579ab375/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts#L855-L957

there's no IR led populated per default.. so this stuff looks just wrong...

 

Maybe things get better once the board reaches mainline: https://patchwork.kernel.org/patch/10745929/

normally the peer review there stops people from messing up stuff.. but this will take some time..

[/rant]

 

Currently, time doesn't allow to dig into it.. I've a lot of other work to do and my rockPi runs productive on mainline for a numbers crushing project I'm in (since 7 days it runs 24/7 at roughly 80°C and it does well here).. So I won't stop it from it only to fix a 4.4 kernel which is broken.. I can have a look into debug from console but not much more..

 

First I would try to boot it from SD-Card not burning images directly onto eMMC.. Attach an USB-UART and provide us bootlogs.. Then we see where it stucks..

 

 

16 minutes ago, chwe said:

Currently, time doesn't allow to dig into it.. I've a lot of other work to do and my rockPi runs productive on mainline for a numbers crushing project I'm in (since 7 days it runs 24/7 at roughly 80°C and it does well here).. So I won't stop it from it only to fix a 4.4 kernel which is broken.. I can have a look into debug from console but not much more..

 

First I would try to boot it from SD-Card not burning images directly onto eMMC.. Attach an USB-UART and provide us bootlogs.. Then we see where it stucks..

Thank you for all the info, that's very helpfull. Did you have contact with the Radxa team about these things?
Indeed their Armbian image was put together very quickly, and it was seen as a preview. It does work well for some goals, but it's not what an Armbian image must be.

It would be better if they drop their Armbian once the official Armbian is up for it.
I've got good contacts with the people at Radxa, I could ask how they see things here. It would be good if a developer of theirs would frequent the Armbian forum too.

Please use a better heatsink for your board, I now have the big heatsink. Now doing a Blender render as test, difference of 30°C

 No fan small heatsink max load    : 85°C throttle keeps rising to 95°C

No fan big heatsink max load        : 65°C
That feels a lot better to my conscience. Some details on the heatsink could be better. But I like it. I screw some legs into the fins. Too bad there's no standard sized holes for them.

I've build a dev image for the RockPi4. First doing some other tests with their Armbian, then I'll see where it's at with the dev. Thanks for the great work.
 

2 hours ago, chwe said:

Green was always on..

This is because the R1823 is in-place providing permanent VCC5V.

I could be removed and then add the R1821 resistor, it will then be driven by GPIO3_D4.

But those SMT0402 resistor are so thiny ...

2 hours ago, martinayotte said:

GPIO3_D4.

This is from the Radxa forum.
 

Quote

StephenRadxa Team

18d

The green LED is the power indicator and is constantly on. It is not controllable via GPIO. While the red LED is controllable.

The two LED series circuits are connected as follows.

+5V — Resistance(1K) — Green LED — GND

RK3399(GPIO3_D5 pin) — Resistance(1K) — Red LED — GND

To operate the GPIO, see https://wiki.radxa.com/Rockpi4/hardware/gpio 16

gpio3_d4 -> gpio3_d5

I don't know which ones correct, just wanted to note it.

1 hour ago, NicoD said:

I don't know which ones correct, just wanted to note it.

Take a look at the schematic :

 

 

GPIO3_D4 goes to UnPopulated R1821 then Green LED but also to PullUp R1823 which need to be removed, while the GPIO3_D5 goes to R1823 then Red LED, already controllable .

 

2 minutes ago, martinayotte said:

Take a look at the schematic :

hehe is it public? Didn't spot in on their page..

 

 

17 minutes ago, chwe said:

hehe is it public? Didn't spot in on their page..

I don't remember where I got it on Jan 3rd ... The file is named ROCKPI-V13-sch-20180901.pdf but Google didn't find it ...

EDIT : I found the source :

@Igor in a PM on Jan 3rd, but I don't know if it can be released, I will leave him to confirm or not ...

15 hours ago, chwe said:

WIP so things like that are expected.. Provide a bootlog and I'll have a look into it..

 

[small to medium rant]

If it's a Raxda produced 'Armbian' things might not work and I'll not fix it.. They decided to use their own 4.4 kernel fork and I'm not willing to look into it. If they want a more stable 4.4 based armbian Image they should contribute to Armbians 4.4 Kernel (basically @ayufan one with some patches). And not something like this:

 https://github.com/brian541/build

We won't maintain a third RK3399 bsp kernel only cause there's a new board out which throws us a bunch of errors with ayufans kernel..

 

That's where their armbian previews came from... The whole device tree looks like a fire and forget push.. e.g.

 

https://github.com/radxa/kernel/blob/155a65a72b20b477663218ce47fd9130579ab375/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts#L645-L707

doesn't make sense at all.. The CSI populated on the board is a 2 lane 'RPi alike one' whereas ov13850 is a 13mp camera normally connected via 4lane mipi csi.. Looks like some leftover from a firefly or so.. Even then, it's on a different i2c bus which also looks fishy..

 

https://github.com/radxa/kernel/blob/155a65a72b20b477663218ce47fd9130579ab375/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts#L271-L286

didn't work.. At least only one LED could be triggered.. or there's a third led somewhere which I didn't spot.. Unfortunately there aren't public available schematics to get a clue how things are soldered together here..

 

https://github.com/radxa/kernel/blob/155a65a72b20b477663218ce47fd9130579ab375/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts#L855-L957

there's no IR led populated per default.. so this stuff looks just wrong...

 

Maybe things get better once the board reaches mainline: https://patchwork.kernel.org/patch/10745929/

normally the peer review there stops people from messing up stuff.. but this will take some time..

[/rant]

 

Currently, time doesn't allow to dig into it.. I've a lot of other work to do and my rockPi runs productive on mainline for a numbers crushing project I'm in (since 7 days it runs 24/7 at roughly 80°C and it does well here).. So I won't stop it from it only to fix a 4.4 kernel which is broken.. I can have a look into debug from console but not much more..

  

First I would try to boot it from SD-Card not burning images directly onto eMMC.. Attach an USB-UART and provide us bootlogs.. Then we see where it stucks..

 

 

 

Thanks for pointing it out. I will have out engineer look at it and clean the device tree. We would like to contribute to Armbian and get some decent support on ROCk Pi 4. Apparently, we should do it in the right way.

10 hours ago, martinayotte said:

I don't remember where I got it on Jan 3rd ... The file is named ROCKPI-V13-sch-20180901.pdf but Google didn't find it ...

 EDIT : I found the source :

@Igor in a PM on Jan 3rd, but I don't know if it can be released, I will leave him to confirm or not ...

 

You can release it. We will polish the schematic formats and release it anyway...

3 hours ago, hipboi said:

Apparently, we should do it in the right way. 

From an early point of development having your own kernel makes sense.. Saves you time and you don't have to deal with other people messing with it which might break stuff for the RockPi and cause you provide your own images based on it it's understandable to use it for some early armbian previews as well. For Armbian as a project it doesn't make that much sense. The more Rockchip boards we can maintain with one kernel source, the less work we have.

 

Something I noticed by looking through your kernel commits:

 

You've started with devicetree overlays right?

As far as I know, the normal workflow to load them is to have the kernel module config_of_overlay (https://cateee.net/lkddb/web-lkddb/OF_OVERLAY.html) compiled. Last time I had config of overlay together with Rockchips ISP driver (http://opensource.rock-chips.com/wiki_Rockchip-isp1) the kernel crashed immediately at booting. Since you claim that the camera works on your images (and from DT it looks like you use isp1) does it also work with device tree overlays? Did I miss something obvious here? Or is DT overlay early wip and not yet implemented?

IMO our efforts should focus on trying to make RockPi work with our RK3399 kernel instead of adapting the rockchip64 kernel for it. As a matter of fact, we recently had to revert a patch from upstream Ayufan's that enabled some features necessary to take full advantage of the RK3399 SoC, just because it made our RK3328 boards fail to boot

Well the kernel discussion is open since a long time.. and we switched from here to there to here to...

 

original goal was once to have RK3328, RK3399 (and if possible RK3288) under one kernelconfig/source.. Something we probably never achieve.. RK3399 kernel is under friendly arms control and I'm not sure if this makes things better ore worse.. They may also adjust stuff just to ensure it works on their NanoPis without issues but don't care about other boardmakers needs. And we support a bunch of different RK3399 boards...

 

The revert shows only kernelconfig.. Do we relay on his kernelconfig as well?

1 hour ago, chwe said:

The revert shows only kernelconfig

Well, yes, those configs were for Mali T8xx, ISP camera driver, and other RK3399 stuff. Without them, all the media features in the SoC are unusable.

1 hour ago, chwe said:

RK3399 kernel is under friendly arms control

Another option could be switching to vanilla rockchip kernel, but it's probably not necessary as long as FriendlyARM's one is not giving any trouble with the other boards. AFAIK, the only problem causing RockPro64 not to be in the RK3399 family is u-boot related, not kernel. Not sure about Rockpi 4b.

 

How about using rk3399's kernel and rockchip64's u-boot, in case there is no way to make rk3399's uboot work with RockPro64?  @TonyMac32 @martinayotte @Igor what do you think?

27 minutes ago, JMCC said:

the only problem causing RockPro64 not to be in the RK3399 family is u-boot related, not kernel. Not sure about Rockpi 4b.

RockPi-4B was simply copied from RockPro64 as a template.

28 minutes ago, JMCC said:

How about using rk3399's kernel and rockchip64's u-boot, in case there is no way to make rk3399's uboot work with RockPro64?

I was thinking the reverse, and started exploring half hour to try Mainline U-Boot v2019.01 working with RockPro64, but it doesn't seem to be trivial for now (defconfig issues).

I will investigate more later ... For now, my task is to have 5.0.y on all my RK3399 boards : RockPro64 is done, now testing OrangePi-RK3399, next will be my NanoPCT4 and RockPi-4B ...

 

Honestly I think we should try to roll a u-boot that works for both, not just glue one into the other or vice versa. Same for kernel, we can keep the vendor kernels for 4.4, but Mai line should be vanilla with patches we track IMHO.

Sent from my Pixel using Tapatalk

8 minutes ago, TonyMac32 said:

try to roll a u-boot that works for both

That is why I wish to get rid of U-Boot SPL 2017.09-armbian used by RockPro64 and RockPi-4B (the latest was only because the first used as template).

If we can get both RockPro64 and RockPi-4B running U-Boot v2019.01, the issue will be solved forever ...

Yes, +1 for mainline u-boot for everyone. After all, u-boot is just about being able to start the board, and the simpler we can do it the better.

6 minutes ago, JMCC said:

mainline u-boot for everyone

Since 5.0.y is now committed, I'm now going back to the task of getting rid of this old U-Boot SPL 2017.09-armbian ...

should we split the thread? It's a way more than just LED for rockchip now..

 

LED's are all encompassing.

Sent from my Pixel using Tapatalk

8 minutes ago, chwe said:

should we split the thread? It's a way more than just LED for rockchip now..

No, let LED continue here, the 5.0.y should continue there :

 

6 hours ago, martinayotte said:

No, let LED continue here, the 5.0.y should continue there :

 

Hello to all,

 

I'm just impressed about your comments for my simple question… 

Many thanks to all who have brought ideas.

 

+1 for Splitting this thread…

On ‎3‎/‎14‎/‎2019 at 5:44 PM, NicoD said:

Hi. Did you try an image from Radxa themself? Is it with eMMC or sd-card?
https://wiki.radxa.com/Rockpi4/downloads

@chwe I build an RockPi4 image today, and it also didn't boot. I tried 3 different eMMC modules. Then installed the Armbian from Radxa on it and this works. But there's no zram there.
I'll see if I can find an sd-card to try it with that. Then I'll try building another image with dev kernel instead.

I got my big heatsink for it today. So I want to set it up as good as possible. But I think I'm gonna stick with the Ubuntu Server from Radxa for the moment.
Cheers.

Hello NicoD

 

Yes indeed the Ubuntu Server image from radxa with SDCard is working fine….  it's just the Armbian