<naobsd>
one more thing, please don't assume that u-boot need to be patched to init mmu properly. it works w/o patch on my rk3288 boards
<naobsd>
I don't say firefly production ver. (0930) must not have any issue. it may have issue.
<naobsd>
to solve issue, please try to make things clear first, and only if something need to be changed, please change something _one by one_
<naobsd>
experts know gcc 4.9.x works fine (on some environment)
<naobsd>
but no one knows it works fine on firefly
<naobsd>
don't assume it must work fine
<naobsd>
firefly -> firefly SDK
naobsd has quit [Quit: Page closed]
levd has joined #linux-rockchip
field^Mop has quit [Ping timeout: 256 seconds]
naobsd has joined #linux-rockchip
levd1 has joined #linux-rockchip
<naobsd>
I think mmind00 never said that mmu issue _must happen_ on firefly
levd has quit [Ping timeout: 245 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 244 seconds]
cnxsoft has joined #linux-rockchip
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 255 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 245 seconds]
RayFlower has joined #linux-rockchip
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 272 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 265 seconds]
<naobsd>
mmm....
<naobsd>
internet connection is very very unstable :(
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 265 seconds]
<naobsd>
11k/101k processed...
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 240 seconds]
cnxsoft has quit [Quit: cnxsoft]
akaizen has joined #linux-rockchip
Astralix has joined #linux-rockchip
Astralix1 has quit [Ping timeout: 250 seconds]
levd has quit [Remote host closed the connection]
levd1 has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
levd has joined #linux-rockchip
<naobsd>
30k...
levd1 has quit [Ping timeout: 258 seconds]
<naobsd>
it seems my firefly is arrived at home
<naobsd>
this time custom duty is about $30 ;)
cyrozap has quit [Ping timeout: 256 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 264 seconds]
cyrozap has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
levd has joined #linux-rockchip
cyrozap has quit [Ping timeout: 265 seconds]
levd1 has quit [Ping timeout: 250 seconds]
FreezingCold has joined #linux-rockchip
cyrozap has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 245 seconds]
<naobsd>
50k/101k!
levd has joined #linux-rockchip
<naobsd>
I should do this work on fastest machine! (too late!)
levd1 has quit [Ping timeout: 265 seconds]
cyrozap has quit [Ping timeout: 265 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 240 seconds]
cyrozap has joined #linux-rockchip
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 240 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
<naobsd>
60k...
<naobsd>
mmm
<naobsd>
I should start this work in background...
cyrozap has quit [Ping timeout: 240 seconds]
levd1 has joined #linux-rockchip
cyrozap has joined #linux-rockchip
levd has quit [Ping timeout: 255 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 265 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
GriefNorth has joined #linux-rockchip
RayFlower has joined #linux-rockchip
cyrozap has quit [Ping timeout: 250 seconds]
cyrozap has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 264 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
cyrozap has quit [Ping timeout: 272 seconds]
RayFlower has quit [Quit: RayFlower]
cyrozap has joined #linux-rockchip
levd has joined #linux-rockchip
AstralixNB has joined #linux-rockchip
naobsd has quit [Quit: Page closed]
levd1 has quit [Ping timeout: 255 seconds]
cyrozap has quit [Ping timeout: 258 seconds]
levd1 has joined #linux-rockchip
antoinemaillard has joined #linux-rockchip
levd has quit [Ping timeout: 264 seconds]
<AstralixNB>
naobsd: Please read my story completely, before requesting me to try this or that or only one by one...
<AstralixNB>
I had the preinstalled Android working on the board
<AstralixNB>
I downloaded the 0930 linux image and flashed it according the readme
<AstralixNB>
Result: Bootloop with kernel crashing at timer or DRAM init.
<AstralixNB>
I downloaded the original 0930 Android image and flashed it
<AstralixNB>
Result: Bootloop at kernels DRAM init
<AstralixNB>
As there is no version printed on the PCB, I just guessed that there where late modifications in the production
<AstralixNB>
So I downloaded latest greatest sources according the firefly wiki and as I only had some 4.7+ gcc at hand, I compiled with the know to work 4.9hf
<AstralixNB>
I found that uboot doesn't like to be compiled with hf, so I used 4.9 non-hf and it works
<AstralixNB>
This uboot does boot all images I downloaded to exactly the same result... With one exception
<AstralixNB>
Now in 60% of the reboots, the kernel crashes at init of DDR, in 30% the kernel runs through to init of frame-buffer devices
<AstralixNB>
Not only me, but also Andrew from firefly forum found, that the sources in the firefly git are somewhat outdated.
<AstralixNB>
I then cross checked the dts settings in the rk3288-firefly.dts and found that some DC/DC outputs are set to different voltages and especially DRAM supply is set to 1.2V instead of the 1.5V that are written in the schematics of the 0930 revision.
<AstralixNB>
And for the compiler: If the kernel boots beyond the timer and DDR init, it doesn't matter. The problematic things that make kernel fail when compiled with 4.9.x are in the Cortex init assembly code. And obviously that is not a problem as in several situations the kernel booted far beyonf that point.
<AstralixNB>
mmind00, correct me if I am wrong, but mainline should be compiled with 4.9hf and that should is meant as an Intel should... i.e. You must!
<AstralixNB>
mmind00, thanks for the DC/DC hints, I try them later
Luke-Jr has quit [Remote host closed the connection]
Luke-Jr has joined #linux-rockchip
<AstralixNB>
Hmm... If I read this, I guess I have been quite deterministic in my approach to check what's wrong.
naobsd has joined #linux-rockchip
<naobsd>
AstralixNB: can you wait some time? my firefly is arrived, I can check some things for you
<naobsd>
I'm using gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux for mainline
<naobsd>
I never said gcc 4.9 cannot be used for mainline
<naobsd>
AstralixNB: if you get SDK, you have gcc 4.6/4.7 for kernel/u-boot
<naobsd>
AstralixNB: it's in SDK. please check
<AstralixNB>
I got confirmation from busybee of firefly forum: uboot version is too old
<AstralixNB>
and the sources in the git are outdated
<naobsd>
AstralixNB: what he said is "I check your kernel version and conclude that you are using the old firmware file."
<AstralixNB>
I used what was presented
<naobsd>
AstralixNB: please point the "outdated" source
<AstralixNB>
About u-boot, v2.17 and above is good for use.
<naobsd>
AstralixNB: can you stop blaming and try to solve your issue?
<AstralixNB>
I didn't blame
<naobsd>
while writing dts for mainline, I found voltage difference
<AstralixNB>
What is available to download is not matching the needs of the hardware.
<AstralixNB>
May be this is more neutral
<AstralixNB>
I am flashing the dualboot image now and then we see
<naobsd>
AstralixNB: then everyone must have issue. right?
<AstralixNB>
May be I have the first defective board
<AstralixNB>
However, let me flash and see if it works
<naobsd>
AstralixNB: btw, which source is "outdated"?
<AstralixNB>
I should not blame, so I tell it to be not-matching
<AstralixNB>
I followed this article to rebuild firefly from scratch
<AstralixNB>
I later used the neo-technology sources to creat the boot.img for mainline
<AstralixNB>
And in the firefly bitbucket I used master
<rperier>
hi all
<naobsd>
please use gcc 4.6 in android sdk even if you really really really sure gcc 4.9 on your machine is fine
<naobsd>
it's required to say something in firefly side is wrong
<AstralixNB>
I did not build android, I just tried to build a simple kernel that boots to init to see if I can boot my board
<naobsd>
once again
<naobsd>
please please please use gcc 4.6 in android sdk to build kernel in android sdk source tree
<AstralixNB>
I can now confirm the following:
<AstralixNB>
the prebuild image for ANDROID with version 0930 build on 2014-12-11 does not work on my board.
<AstralixNB>
the prebuild image for LUBUNTU with version 0930 build on 2014-12-11 does not work on my board.
<AstralixNB>
the prebuild DUALBOOT image with version 0930 build on 2014-12-11 DOES WORK on my board.
<rperier>
personally, I already build my mainline kernel with 4.9.x
<rperier>
(I use yocto dizzy here which ships gcc 4.9)
<naobsd>
AstralixNB: I see. I'll do same on my firefly
<rperier>
however, it's only on rk3188 for now
<AstralixNB>
rperier, as naobsd said and I confirmed: mainline + 4.9hf = GOOD!
<AstralixNB>
same here, rperier
<naobsd>
I _never_ say don't use gcc 4.9 and/or use gcc 4.6 for mainline
<AstralixNB>
I am aware of the following: If you have the right kernel code, you can compile Android kernel for RK3188 with 4.9.2hf
<AstralixNB>
You must compile Android with 4.6
<AstralixNB>
Then you have a high speed system
<AstralixNB>
This works on several RK3188 devices we have tested (and we have tested lots of them)
<AstralixNB>
But if a kernel fails on 4.9 with android, you have to go back to 4.6 and it will work in 98% of the cases
<AstralixNB>
With that, naobsd is fully right
<rperier>
naobsd: I think that AstralixNB is a bit frustrated, that's understandable... he got a new firefly board which does not work at all, it's not blames
<AstralixNB>
No, I am not frustrated
<AstralixNB>
totally not
<AstralixNB>
But it is as always in the past 4 Years I am actively hacking rockchip based devices
<rperier>
no, I mean, you're perhaps a bit irritated
<AstralixNB>
Some yells: "Hey guys I have something great and find and big" and all of us jump on that train and wna to develop and then...
<AstralixNB>
non matching images
<AstralixNB>
non matching soruces
naobsd has quit [Ping timeout: 246 seconds]
<AstralixNB>
non matching schematics
RayFlower has joined #linux-rockchip
naobsd has joined #linux-rockchip
<naobsd>
I _never_ said everything from firefly must be perfect
<AstralixNB>
But as firefly only started to ship boards, there is still time to fix wiki, links and images
<AstralixNB>
We should post a hint in the wiki what version to checkout exactly.
<AstralixNB>
If you switch youtube video quality to 720p or 1080p in full screen you can hear the fan speed dropping a bit. But I use the board with the USB adapter at a 5A powered USB3 HUB.
<AstralixNB>
Hmmm....
<AstralixNB>
levd1: I had the board running in linux now for some minutes...
FreezingCold has quit [Ping timeout: 240 seconds]
<AstralixNB>
In the last few minutes it just showed a youtibe overview screen ...
<AstralixNB>
And then it went black
<AstralixNB>
And now I have the same issue like yesterday
<karlp>
sounds like a problem I was having with a minix neo x5 mini,
<karlp>
but minix have "upgraded" their forums so I can't double check
<AstralixNB>
lol
<karlp>
but it was pretty much the same thing, "this source works for other people, at least allegedly, but just continually reboots for me"
<karlp>
in the past, the old forums were just locked, now they're empty and deleted. thanks minix.
<AstralixNB>
I wonder if it again works if I reflash the image..
<AstralixNB>
no, it doesn't help
<AstralixNB>
Ok... Looks like I got one point....
<AstralixNB>
Using the original power adapter and the board works again
<AstralixNB>
I need to buy an US Euro adapter as using lab clamps and test cords will not work at home with children around...
<AstralixNB>
The power of a really big fat USB 3 HUB is not enough to run the firefly...
cnxsoft has quit [Ping timeout: 240 seconds]
antoinemaillard has joined #linux-rockchip
field^Mop has joined #linux-rockchip
naobsd has joined #linux-rockchip
<naobsd>
(still on the train)
<AstralixNB>
Hi!
<naobsd>
AstralixNB: are you using FAN? I guess it may make power line unstable
<AstralixNB>
I am using the fan
<naobsd>
FAN must be optional
<naobsd>
I know RK3288 can be very hot
<AstralixNB>
Yes, but as the heat spreader comes without glue or pad, I preferred the fan
<naobsd>
I'm using firefly beta without extra heatsink and/or fan
<AstralixNB>
RK SDKs are coming without any heat spreaders too
<naobsd>
it can reach 100C degree or more only when I run intensive work on all 4cores
<naobsd>
you can check stability (boot or not) without fan
<naobsd>
what I'm thinking is about power line stability
<naobsd>
I never tried fan
<naobsd>
but my RK3288 boards can boot with AC-USB 5V2.1A
<AstralixNB>
Other than radxa rock, the 5V train is not cut off at power down. So the fan runs as long as the board has a supply connected
<naobsd>
but -> btw
<AstralixNB>
May be there is a different position where to connect the fan, so it is switched with "logical" poewwr
<AstralixNB>
I now use the 5V/3A supply that was in the envelope together with the firefly. I'll go and buy an adapter this evening. But I will do some power testing the next days at home at my programmable power supply unit.
<naobsd>
I'm not hardware person, but I think fan makes noise
<AstralixNB>
There is chance for this. On the other hand, a simple 1ct cap could avoid such problems if placed right
<naobsd>
"if placed right" <- this is what I don't know ;)
<AstralixNB>
hehe
<naobsd>
anyway you can try boot test w/o fan
<naobsd>
and I think I can try too
<AstralixNB>
sure
<AstralixNB>
give me a second
<naobsd>
train train...
<AstralixNB>
need to modify init script to start right HDMI mode
<AstralixNB>
starting via USB HUB supply and without fan
<AstralixNB>
Ok, operating temperature is max 125°C
<AstralixNB>
This should give some range for fanless operation
<naobsd>
125 degreeC is possible by full load, but I think it will not happen on "just booting" ;)
<AstralixNB>
The operating temperature is taken from RK3288 datasheet
<AstralixNB>
I would personally prefer to have a heatsink applied, but I don't think that a fan is needed too.
<AstralixNB>
However, if the power train is upset by just the fan, there is a chance that it works at its limits even without a fan. The fan just tips it over the limit.
<AstralixNB>
anyway, time for lunch now...
apritzel has joined #linux-rockchip
antoinemaillard has quit [Quit: antoinemaillard]
<AstralixNB>
I have to admit, that the fan has it's own connectors, what I didn't see... I connected it to the upper 5V on the right connector.
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
naobsd has quit [Ping timeout: 246 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
antoinemaillard has joined #linux-rockchip
naobsd has joined #linux-rockchip
<naobsd>
I see, 0930 has FAN+/- pins
<naobsd>
then, it doesn't make USB hub power unstable?
<AstralixNB>
Yes and with connecting the fan to these pins, the board works more reliably if supplied by USB
<naobsd>
I see, then fan is not source of problem
<naobsd>
but your USB hub power is not reliable, is it?
<mmind00>
AstralixNB: I don't know if you have resolved this meanwhile, but I don't think the compiler matters much ... I mainly use "gcc-arm-none-eabi-4_7-2013q2" i.e. some older Linaro release
<AstralixNB>
On the lower side of the PCB there are two bigger caps.
<AstralixNB>
Hi mmind00, at least with the DualBoot image, we could reduce the problem to the connection of the fan.
<AstralixNB>
naobsd, I am searching the schematics as it has FAN+ and FAN- on the U26 connector (page 20) but there are no other traces found with these labels.
<naobsd>
AstralixNB: well, you said fan make more reliable...
<AstralixNB>
no, using the FAN+/- connectors instead of the 5V/GND on the other end of the same U26 connector, makes the board work more reliable
<naobsd>
AstralixNB: yes, schematics doesn't give any info
<AstralixNB>
If you tka it right, these pins are labeled but not connected, but as the fan rotates, it is probably an error in the labeling
<naobsd>
let's unpack my firefly
<AstralixNB>
lol
<AstralixNB>
take your time
<naobsd>
ganbold_: I'll check & flash some image both boards, ok?
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
<ganbold_>
naobsd: ok
<naobsd>
AstralixNB: can you see "2014.09.30" near bottom of eMMC?
<AstralixNB>
Yes
<naobsd>
it's board version
<AstralixNB>
so this is the unzipped version of 0930
<AstralixNB>
This should be explaind on the wiki as well as the assembly of the case kit and the correct connection of the fan.
<AstralixNB>
Board is running fine now with the DualBoot and the fan connected to the right pins and on USB3 HUB
<naobsd>
FAN+ and FAN- is printed on the board
<naobsd>
I'll upload photo soon...
<AstralixNB>
I know+
<AstralixNB>
now...
<AstralixNB>
naobsd, if you check the bottom side of the board, you can see the bigger yellow caps right aside the U26 connector. I guess this is the reason why the board survives the fan
<naobsd>
AstralixNB: can you check another image with right fan connection?
<AstralixNB>
what?
<AstralixNB>
where?
field^Mop has quit [Ping timeout: 272 seconds]
<AstralixNB>
I can take some pictures if you like
<naobsd>
Android image and Luubntu image, anything that you said it doesn't boot
<AstralixNB>
you mean a screenshot of this bootloop?
nighty-_ has joined #linux-rockchip
<naobsd>
AstralixNB: did you try those images _after_ you connected fan with right pin?
<AstralixNB>
Ah, now i understood
<AstralixNB>
As the dualboot failed after some time of use too, and it doesn't fail now... I didn't check the other images again
<AstralixNB>
however, I can do so, just give me some minutes
<AstralixNB>
hmmm
<AstralixNB>
I pulled off the shield and unplugged the fan
<AstralixNB>
now the board just hangs in the boot loop again
<AstralixNB>
No fan attached
<AstralixNB>
plugging in original power supply, the board works again
<AstralixNB>
This firefly is very picky about its supply...
<naobsd>
or USB hub is not reliable
<naobsd>
I recommend to use original power supply to check software stability
<naobsd>
rperier: there is only 1 power supply in a set
<rperier>
okay, nice
apritzel has quit [Read error: Connection reset by peer]
<naobsd>
you may use USB-DC cable with your AC-USB adaptor
<AstralixNB>
That should work if you have a somehow powerfull AC-USB wallplug.
<AstralixNB>
I do have several ones at home and I'll check which of them work in the next days.
<rperier>
I will be careful about power supply
cosm has joined #linux-rockchip
<naobsd>
http://pastebin.com/u73kemPa Firefly-RK3288_Android4.4_201412111722.img booted with fan with bundled power supply
<AstralixNB>
Looks like mine, if correctly powered
<AstralixNB>
I just wanted to ask if there is no HDMI audio in linux, but after the last reboot, it is playing audio... even the volume regulator doesn't work and the audio is distorted heavily.
<AstralixNB>
And after all of the 930 images seemed to fail, I tried the older images
<naobsd>
but currently only 1211 images are available
<AstralixNB>
Cause I didn't see the tiny little date code under the NAND, I thought, maybe that is a beta-board
<AstralixNB>
Hmm... I see
<AstralixNB>
they have exchanged all of them
<AstralixNB>
I need to download them again
selfbg has quit [Quit: Leaving]
<naobsd>
busybee said your image is old, try googld drive one, that is 1211 firm. it's right suggestion
<AstralixNB>
yes
<AstralixNB>
I do
<AstralixNB>
ups
<naobsd>
I don't have Firefly-RK3288_Android4.4_201411111636.img, I cannot try it
<naobsd>
anyway you should mention clearly
<AstralixNB>
I can confirm that the 1111 Image works with the wallplug used as power supply
<naobsd>
I didn't know I tried different firm :(
<naobsd>
then I think problem is the power supply
<AstralixNB>
yes
<naobsd>
firefly's document should have several issues
<naobsd>
but it's another problem
<naobsd>
I'll try dual boot image just for completeness...
<AstralixNB>
It works perfectly if you supply enough amps :)
<naobsd>
hey
<naobsd>
the reason I have to try these images is... for you.
<AstralixNB>
so kind of you
<AstralixNB>
flashing 1211 image of ubuntu now as android 1111 tests finished
<AstralixNB>
The linux image never hits the correct HDMI setting and sometimes after setting the HDMI mode via command line, the monitor output is wrong...
<AstralixNB>
however if it works, it works fine.
<AstralixNB>
720p video in software on youtube
<AstralixNB>
Ubuntu image 1211 works
<AstralixNB>
And the Dual-Boot image 1211 I have already teste half of the day
<rperier>
nice to read this
<AstralixNB>
So we can definately state that you should keep an eye on a clean and bit powerfull supply
<AstralixNB>
And I ran all tests with fan installed and running!
<AstralixNB>
I now reflashed to the uboot I compiled on my own
<rperier>
I just need to find another AC-USB adapter (wallplug) because the one shipped by radxa for the rock pro is not powefull enough I think, but good to know that everything is alright for you
<rperier>
I will play with my rock pro and my firefly during holidays :D
<AstralixNB>
It works!
<AstralixNB>
Yes, me too
<AstralixNB>
rperier, I had no fears for myself, I just feared about all the newbies that plug in the board into any kind if USB supply and then the have everything from not working, to bootloops to random crashes
<AstralixNB>
We got the boards for free (at least if you don't count in these ugly duties) so it is our job to report on any possible error
<naobsd>
firefly team did/are doing good work even if it's not perfect
<naobsd>
we can help them
<AstralixNB>
naobsd: confirmed. The work is fine, the documentation is incomplete.
<rperier>
AstralixNB: sometimes even qualified people do stupid mistakes, for example I was very afraid about electrical stuffs on my rock pro, because I did not had uart debug output... the issue only came from my usb ttl converter, electrically everything is okay... it happens sometimes :)
<naobsd>
sorry, I have no right to mention about document incompleteness ;)
<AstralixNB>
Even I might have a rough way of talking I was never angry. I just acted like the standard user...
<rperier>
perhaps it is not perfect yet, but this is their first board...
<rperier>
(I am talking about the firefly company)
<naobsd>
standard user never mention about mmu code!
<AstralixNB>
hehe
<AstralixNB>
No, I meant, buy, unpack, supply, doesn't work...
<naobsd>
and never try to recompile u-boot/kernel himself ;)
<rperier>
I never said that it was normal :)
<AstralixNB>
I started with what any normal user would have done too!
<AstralixNB>
I just tried to download and install the available images
<naobsd>
I see ;)
<naobsd>
yes, sure.
<AstralixNB>
Later I tried to get it working again
<rperier>
you did it right
<AstralixNB>
The rock1 never had any issues running on the very sane USB HUB as a supply
<AstralixNB>
So I was not aware of the power issue
GriefNorth has joined #linux-rockchip
<AstralixNB>
I started thinking about power as suddenly the kernel crashed at different positions.
<naobsd>
hm
<naobsd>
I thought DDR is defected because of _random_ crash
<AstralixNB>
And then I saw that in the schematics and the kernel dts files are different voltages set for the different regulators
<naobsd>
it was impossible that writing mainline dts with schematic only
<naobsd>
I checked 3.10 kernel dmesg
<naobsd>
working code should be more reliable ;)
<AstralixNB>
So may be I jumped on that dts thing to fast instead of using just a different power supply. But it was somehow problematic as the supply as US plug and I live in germany...
<AstralixNB>
Why was it impossible to write dts with onyl the schematics?
<naobsd>
ah, I'll try my reliable AC-USB adaptor...
<AstralixNB>
if you need some more detailed information about clocks and power constraints, just ask... there are people in here that have some more documents of the RK SOCs
<naobsd>
and we can ask
<AstralixNB>
I definately would like to ask for two things:
<AstralixNB>
1) updated latest schematics (where the fan is connected to somewhere)
<AstralixNB>
2) wiki entry showing exactly the git tag or branch that works reliably for android and linux
<rperier>
naobsd, AstralixNB: do you plan to do mainline development for this board ?
<AstralixNB>
At least I like to support you guys as good as I can
<naobsd>
I have to do many other things...
<rperier>
just to know, don't worry :)
<AstralixNB>
Most of us will do this in their free time. So if company projects ramp up or family requests your attention or whatever...
<jas-hacks>
question, how the does the bootrom determine if it needs to boot from SD or eMMC?
<naobsd>
my AC-USB works fine
<AstralixNB>
Just let it run for half an hour and see. My DualBoot image failed after 30min starting right into a reboot with boot loop to follow
<naobsd>
jas-hacks: if 1st media is available, it tries to boot from 1st media. if 1st media is not available, it tries to boot from 2nd media. if 2nd media is not available, it tries to boot from 3rd media.
<naobsd>
oh, I should insert power meter...
<naobsd>
well, I can try at any time. for now, I want to try mainline...
<jas-hacks>
thxs, what is the priority order of the media?
<AstralixNB>
let me see
<naobsd>
jas-hacks: it may vary by SoC type
<naobsd>
jas-hacks: we know some from experience, but there is no reliable official document
<naobsd>
jas-hacks: which SoC do you want to know?
<jas-hacks>
firefly - RK3288
<AstralixNB>
naobsd, you are right, there are copy-paste errors in the docs from RK
<AstralixNB>
1) NAND
<AstralixNB>
2) eMMC
<AstralixNB>
3) SPI/NOR
<AstralixNB>
4) SDMMC
<AstralixNB>
5) USB
<naobsd>
AstralixNB: it's "right" info for rk3288?
<naobsd>
I have no experience with NAND and SPI/NOR on rk3288
<AstralixNB>
But as we all know, you can just insert an image on SD and it boots from SD so this excerpt from the TRM above is probably as wrong as it was for RK3188
<naobsd>
ah, I see
<naobsd>
we know eMMC > SD > USB
<jas-hacks>
I was wondering whether SD will override eMMC
<AstralixNB>
Probably yes
<naobsd>
jas-hacks: as far as I know, no
<AstralixNB>
Hmmm.... SD is often used in production process
<AstralixNB>
But if the eMMC / NAND flash is empty, there is no token and so the MASK ROM loader proceeds right down to SD
<naobsd>
there is SD boot image for rk3288, but I think that is "mask rom load loader on eMMC, then loader on eMMC load other things on SD"
<naobsd>
AstralixNB: yes, I confirmed it by erasing eMMC
<AstralixNB>
ok, so you can confirm eMMC before SD?
<AstralixNB>
as SD only boots if eMMC is clean
<AstralixNB>
We have to try that, I guess
<naobsd>
I put 2 different loader on eMMC and SD, and I confirmed loader on eMMC is booted when SD is inserted
<AstralixNB>
cool for the work, not so cool for the result :)
<naobsd>
and if I erased eMMC, loader on SD is booted
<AstralixNB>
Did anyone ever test an RK3188 with eMMC / SD?
<AstralixNB>
cause in RK3188 there is written NAND before SD too but if you plug in SD with loader it boots from SD regardless of the NAND
<naobsd>
Tony have RK3188 with eMMC, and I think he said something... probably SD is prior
<naobsd>
yes, SD > NAND on rk3188
<AstralixNB>
Document of RK3188 tells NAND prior to eMMC, but it doesn't tell about AD
<naobsd>
I don't believe TRM about boot order ;)
<AstralixNB>
There is no need to believe, we already proved it to be wrong
cnxsoft has quit [Remote host closed the connection]
<naobsd>
jas-hacks: you can configure u-boot as 2nd stage loader, then 1st stage loader loads 2nd stage loader from "uboot" partition, then u-boot loads kernel from boot or kernel partition
<AstralixNB>
what adds the remote
<AstralixNB>
Then they tell to "git pull bitbucket master:master"
<AstralixNB>
But they forgot the fetch?
<naobsd>
pull is fetch&merge
<AstralixNB>
akre you sure?
<naobsd>
yes
<mmind00>
naobsd: if you mean the timer7 issue ... mainline won't have (nor get) a fix, as it is a uboot matter ... you can only grab the workaround from my devel/for_broken_bootloaders branch
<AstralixNB>
Cause I installed and pulled as described on the 17th of december
<naobsd>
AstralixNB: 8fad06cc3bbe6085b74b5920dcc4bc98ab6e8425 should be latest
<AstralixNB>
but I did a fetch now and get over 300MB of updates?
<AstralixNB>
yes, exactly
<AstralixNB>
I am at 99% with 348MB fetched
<naobsd>
there is newer commits pushed 5 hours ago
<naobsd>
in pad branch
<AstralixNB>
Ok, that one is new
<naobsd>
mmind00: thank you. but I have no idea why AstralixNB's mainline kernel can boot with non-patched u-boot :(
<AstralixNB>
naobsd, I check again tonight and keep you updated. And I made the two-line modification mmind00 mentioned yesterady for the MMU init code
<AstralixNB>
I need to reset and try again
FreezingCold has joined #linux-rockchip
<naobsd>
I need to add mmu fix to my u-boot
<naobsd>
but I have to check 2nd firefly board now...
<naobsd>
sleeeeepy.....
<AstralixNB>
naobsd, which mmu fix? The one I added was in head.S in kernel, not uboot
<naobsd>
firefly/master should be same as master on bitbucket
<naobsd>
currently only us mirror is available... ("git repo restore" work is not finished yet)
cosm has joined #linux-rockchip
field^Mop has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
field^Mop has quit [Ping timeout: 244 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
jas-hacks has left #linux-rockchip [#linux-rockchip]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
_andrew_ has joined #linux-rockchip
<_andrew_>
Hi folks
<_andrew_>
So I have current linux-next + some patches booting on the Firefly (albeit with some issues). I'm currently using the shipped U-boot. But thought I'd try a newer one. So I downloaded RK3288UbootLoader_V2.19.01.bin as linked to in here earlier and flashed it to the uboot partition (I thought that seemed logical) however I still just get the shipped uboot. So which partition does uboot actually live in? And what lives in the uboot partition
<_andrew_>
?
RayFlower has quit [Quit: RayFlower]
strange has joined #linux-rockchip
<strange>
any radxa pro users here?
RayFlower has joined #linux-rockchip
<apritzel>
_andrew_: which command did you use to flash u-boot
<apritzel>
upgrade_tool ul RK3288Loader_uboot_V2.15.bin works for me
<Astralix>
If you look at page 10, the eMMC can be partitoned and supports a boot section.
<Astralix>
The eMMC partitons are handled in a way that they exclude cross-partiton wear-leveling.
<Astralix>
So boot is protected by certain mechanisms that avoid that a broken write will ever touch the loader.
<_andrew_>
Yeah, my emmc has 14/15 partitions it has one called boot, but I don't think that is for uboot or anything, it seems to be used for some kernel image or something.
<Astralix>
no, this is not the boot that is meant by RK startup sequence
<Astralix>
This one is protected and requires special flash commands to be issued for access. You can ask naobsd, he collected lots of information around this when he upgraded his rkflashtool to the ultimate
<_andrew_>
There does seem to be a 4MB area before the parameter etc partitions start is that it?
<_andrew_>
Any idea what the uboot partition is for then?
RayFlower has quit [Read error: Connection reset by peer]
<Astralix>
Same datasheet, page 12, there is the partition layout
<Astralix>
as I told you, there is an option to use a loader to start a loader
RayFlower has joined #linux-rockchip
<Astralix>
if you like, you can simply skip that partition if you make your own custom rom
<_andrew_>
Loader starting a loader must be disabled by default otherwise the uboot I flashed into uboot would have got run I guess.
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
<AstralixNB1>
may be this uboot needs one of these RK signatures like all the other booted images too?
<AstralixNB1>
I just read something about that somewhere, but cannot recall at the moment
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
GriefNorth has quit [Ping timeout: 264 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
<Astralix>
when I read the datasheet, I wonder if RK already supports this extended features of their XDHC ports. 200MHz DDR access to eMMC... if the layout of the board fits...
RayFlower has quit [Quit: RayFlower]
<naobsd>
Astralix: I saw the word "HS200" in dmesg, but I don't detail
<AstralixNB1>
ah, nice to hear that.
<naobsd>
Astralix: _andrew_: as I wrote here some hours ago, you may configure u-boot as 2nd loader. then you can flash RK mini/miniall loader to loader area, and flash u-boot (uboot.img) to uboot partition
<AstralixNB1>
yes, that was something I read about
<AstralixNB1>
but I think more of how to get a full featured uboot so you don't need the loader-loaad-loader mess
<naobsd>
this form is _MUST_ if you're using NAND because NAND access code is only in miniall loader
<naobsd>
but optional for non-NAND media
<AstralixNB1>
you mean as the loader needs to present the SRAM loader image to the MASK ROM?
<naobsd>
yes. I use 2nd loader only when it's nedded
<AstralixNB1>
there was a RK3188 uboot that had this inside...
<naobsd>
sorry, SRAM loader?
<naobsd>
as far as I know, DDR init code is loaded to SRAM, and "loader" we called is loaded to DDR
<AstralixNB1>
the MASK ROM loader loads a minit image into the SOC internal SRAM, that then fires um external storage. #