<Tony_>
3.3 part. there are only bits information about firmware.
samfashi has joined #linux-rockchip
<kurain>
and there is one thing I have to say, actually I am working on Allwinner a31 chip but with ap6234 bt&wifi module. and I have make the wifi module working according to the guide and code of rockchip which have firmware of ap6234, but now I hang on bt stack and I don't know which firmware to use
<kurain>
anyway, thanks for your help.
<Tony_>
okay, my device use the AP6330, maybe i can see it's log and ensure which firmware used.
<naobsd>
(I didn't read, just checked source tree)
<naobsd>
mmm, some file cannot be open on web...
<naobsd>
I have local copy but I cannot upload now
GriefNorth has joined #linux-rockchip
Astralix1 has joined #linux-rockchip
Astralix has quit [Ping timeout: 250 seconds]
akaizen_ has joined #linux-rockchip
<kurain>
AFAIK, I know the bt stack use *.hcd as firware I have tried bcm43341b0.hcd
<kurain>
but it seems not work properaly
levd1 has joined #linux-rockchip
akaizen has quit [Ping timeout: 258 seconds]
levd has quit [Ping timeout: 245 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 252 seconds]
benja`_ has joined #linux-rockchip
hramrach_ has quit [Remote host closed the connection]
benja` has quit [Ping timeout: 258 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 264 seconds]
kurain has quit [Ping timeout: 264 seconds]
hramrach_ has joined #linux-rockchip
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 252 seconds]
kurain has joined #linux-rockchip
kurain1 has joined #linux-rockchip
kurain has quit [Ping timeout: 255 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 264 seconds]
kurain1 has quit [Remote host closed the connection]
kurain has joined #linux-rockchip
kurain has quit [Remote host closed the connection]
kurain has joined #linux-rockchip
kurain1 has joined #linux-rockchip
kurain has quit [Ping timeout: 256 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 264 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 250 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 258 seconds]
samfashi has quit [Remote host closed the connection]
samfashi has joined #linux-rockchip
antoinemaillard has joined #linux-rockchip
eebrah has quit [Quit: Lost terminal]
naobsd has quit [Ping timeout: 246 seconds]
dlezcano has joined #linux-rockchip
markm_ has quit [Ping timeout: 250 seconds]
akaizen_ has quit [Ping timeout: 258 seconds]
akaizen has joined #linux-rockchip
markm_ has joined #linux-rockchip
mrcan_ has quit [Remote host closed the connection]
mrcan has joined #linux-rockchip
mrcan has joined #linux-rockchip
mrcan has quit [Ping timeout: 252 seconds]
mrcan has joined #linux-rockchip
AstralixNB has joined #linux-rockchip
mrcan_ has joined #linux-rockchip
mrcan has quit [Ping timeout: 272 seconds]
selfbg has joined #linux-rockchip
<rperier>
hi all
<rperier>
what kind of micro sd card do you use for your RR ?
<AstralixNB>
SanDisk Extreme
<rperier>
I mean, I can use any µSD card of any class ?
<rperier>
like µSD card HC class 10 ?
<AstralixNB>
Yes
<AstralixNB>
But it is only used with mx. 50/50MB/s Read/Write
levd1 has joined #linux-rockchip
<AstralixNB>
As mmind00 figured out, the speeds above 50 require additional hardware inside the SOC that will be available in 3288 but not in 3188
<AstralixNB>
So if you put in a XDHC card it will only be used with medium speeds.
levd has quit [Ping timeout: 250 seconds]
akaizen_ has joined #linux-rockchip
<kurain1>
@ Tony_ , ap6234 bt stack is finished
akaizen has quit [Ping timeout: 258 seconds]
<kurain1>
I got the bt & wifi firmware from amlogic upstream driver
levd has joined #linux-rockchip
<rperier>
AstralixNB: I don't care about the speed I just cant to use a bootable media
<rperier>
problem being there are regressions with linux-next sometimes (or linux mainline in general), I need to be able to boot a rootfs from different source of media
<Tony_>
kurain1, congrats.
<rperier>
like nfs, usb or sdcard
<AstralixNB>
hehe... If you ever bootet Linux on RR from a 45/45 card, you'll never go back to NAND :)
<rperier>
and as sdcard seems to be the more stable...
levd1 has quit [Ping timeout: 264 seconds]
<AstralixNB>
Yes, I do it the same way. I have rootfs on card and kernel in NAND. If you use RK3188Loader, don't forget to add a dummy boot.img somewhere.
<linuxium>
Works on both RK3188 and RK3288 (thanks to naobsd's binary headers for SD boot) and for both Android and Linux ... so you can be running Android and boot Linux from SD card or running Linux and boot a different Linux kernel and RFS from SD card or any combo you want
dlezcano has quit [Ping timeout: 264 seconds]
dlezcano has joined #linux-rockchip
dlezcano has quit [Ping timeout: 255 seconds]
dlezcano has joined #linux-rockchip
<lioka>
linuxium: upgrade_tool ?
<lioka>
linuxium: what's that ?
<karlp>
the linux tool from rockhip for flashing stuff
<naobsd>
linuxium: can you boot from SD without erasing loader on eMMC?
<naobsd>
linuxium: can you boot from SD without erasing loader on eMMC on RK3288?
<linuxium>
yes, that is why I've suggested this as an option now
<naobsd>
oh
<naobsd>
I cannot check your image now... did you modify header or something?
<linuxium>
you need RK3288Loader_uboot_V2.17.02.bin flashed as your bootloader though on the eMMC
<naobsd>
ah, I didn't try it...
<naobsd>
then, u-boot on eMMC checks SD card and if it has parameter etc, it boots from SD
<naobsd>
I'll check latest u-boot for rk3288 later...
<naobsd>
I guess latest u-boot is 2.19
<naobsd>
btw
<naobsd>
very recently I want try "u-boot on on-board flash try to boot from SD" :)
<naobsd>
on RK3066
<naobsd>
btw RK's RK3288Loader_uboot_V2.17.02.bin include fix for R28/R89
<linuxium>
I found V2.17.02 supported it and I haven't check later versions (maybe the wrong assumption to make)
<naobsd>
commit log was not mine, but I confirmed that problem was surely fixed
<naobsd>
so any newer u-boot binary can be used on R28/R89 safely
<naobsd>
but flashing bootloader to on-board flash should be done carefully
<linuxium>
also my source from Firefly for RK3288Loader_uboot_V2.17.02.bin didn't include fix for R28/R89 ... but I haven't sync'ed for a week so maybe now it does
<naobsd>
basically eMMC pins are not able to short
levd1 has quit [Remote host closed the connection]
levd has joined #linux-rockchip
<naobsd>
if you flash bootable but non-functional(panic, freeze, etc) loader and unable to flash functinal loader,
<naobsd>
and if there is no way to go mask rom mode(no pad/hole), it will be complete brick
hipboi_ has joined #linux-rockchip
<naobsd>
u-boot in tablet SDK and RBOX SDK are not synced, I'll check both
<naobsd>
but if there is boot problem, R28/R89 has holes for mask rom mode
<naobsd>
it can be unbricked (unless eMMC is completely broken by unknown reason)
<linuxium>
interesting, even in mask rom mode I cannot flash on my Orion and boot from sd confirms it cannot see any onboard eMMC ... so if you kill your onboard eMMC (including loader) my experience is that sd boot will still work
<naobsd>
linuxium: your eMMC is somehow completely broken, so "bootable but non-functinal loader" cannot exist on eMMC
<naobsd>
then your board is always try to SD boot
hipboi has quit [Ping timeout: 264 seconds]
<naobsd>
what I talked is "bootable but non-functinal loader is on eMMC" case
<naobsd>
it always try to boot from eMMC
<naobsd>
if there is no pad/hole, you cannot stop booting from eMMC
<naobsd>
and bootloader on eMMC is non-functional == same as brick
<linuxium>
ah, so bootable but broken means it can never get to sd loader ... therefore, best now to test loader on sd card first and if works then flash to emmc
<naobsd>
linuxium: yes
ganbold_ has joined #linux-rockchip
<naobsd>
if there is no pad/hole, get working loader binary, then wipe emmc, then try new loader by sd boot
<naobsd>
don't flash unreliable loader to eMMC
<naobsd>
dev board should have a key to enforce mask rom mode ;)
<naobsd>
PX2 has pads, but very small, I have to short them very very carefully :(
<naobsd>
PX2 -> Rayeager PX2 board
<AstralixNB>
I am not sure about that all
<AstralixNB>
I flashed mainline test yestaerday, as you might remember, naobsd
<naobsd>
AstralixNB: yes
<AstralixNB>
today the rock doesnt boot from SD nor NAND
<naobsd>
oh
<linuxium>
AstralixNB: which bit?
<AstralixNB>
bit?
<linuxium>
which part of 'about that all' i.e. what are you unsure of?
<AstralixNB>
I feel like having a virus that kills RK3188
<AstralixNB>
My tablet just tells SHA Error or CRC Error regardless if I boot from SD or NAND. So DRAM must be dead
<AstralixNB>
the rock1 I have booted lubuntu fine for weeks now. running it totally from an SD Card
<AstralixNB>
yesterday I flashed mainline kernel and tested a bit
<AstralixNB>
Today I put back in the SD with lubuntu and it doesn't start anymore
<linuxium>
didn't you say RFS on SD?
<linuxium>
as in before, or yesterday, or on another thread?
<AstralixNB>
RFS?
<linuxium>
root file system
<AstralixNB>
Ah
<AstralixNB>
This I have at home.
<AstralixNB>
Here I have full system on SD...
<naobsd>
AstralixNB: just a guess, but DRAM or CPU may be damaged...
dlezcano has quit [Ping timeout: 252 seconds]
<linuxium>
full system? bl, ram, kernel, rfs or just some components?
<AstralixNB>
full system... but I may have messed up...
<naobsd>
linuxium: you should mention "flashing new loader may brick your board completely" even if you tested well
<AstralixNB>
Wrong card... I have an L on the one running completely from SD and a T on the one just having rootfs
<AstralixNB>
naobsd... I have no confirmation that it is possible to really kill a board with flashing loader
<naobsd>
(un)fortunately, on RK3066/RK3188 age, 99.99% of RK3066/RK3188 devices can use same loader binary (oh, Rockchip, well done, you made almost universal loader binary!)
<naobsd>
people learned any loader binary is safe(not true)
<AstralixNB>
There are two different binaries for RK3188 and RK3088
<naobsd>
they learned flashing random rom image which includes loader binary are safe too
<naobsd>
(not true)
<AstralixNB>
ah... ouch...
<AstralixNB>
no, it is not true. It will not kill your board, but it will need a lot of experience to recover from some situations
dlezcano has joined #linux-rockchip
<naobsd>
AstralixNB: I'm talking loader for RK3066 is (almost) unversal on RK3066, and loader for RK3188 is (almost) universal on RK3188
<AstralixNB>
ok
<naobsd>
it may be started since RK29 age
<naobsd>
but it was not true at RK28 age
<AstralixNB>
you need to check that yor loader supports the DRAM and NAND chip you have inside your box.
<naobsd>
there were some incompatible loader binary, some people knows it may brick device
<AstralixNB>
therefore you need to have documents from RK
<naobsd>
but now people don't think random flashing makes brick
<AstralixNB>
But how should it brick the device?
<naobsd>
if there is a way to go mask rom mode, there may be possible to unbrick
<AstralixNB>
yes
<naobsd>
but if it needs very special loader, and it was lost by flashing random loader,
<AstralixNB>
this requires to short some NAND pins wht requires some ESD precautions
<naobsd>
and if official download is not available,
<AstralixNB>
yes, then you only can try
<naobsd>
if you can go to mask rom mode, how do you get working loader binary?
<AstralixNB>
you can try to pick loaders from other devices
<naobsd>
if there is no binary, it cannot unbrick
<naobsd>
hey, please read
<naobsd>
<naobsd> but if it needs very special loader, and it was lost by flashing random loader,
<naobsd>
it may be very rare case
<AstralixNB>
There are no very special loaders
<naobsd>
but possible case
<naobsd>
no, there is
<AstralixNB>
??
<naobsd>
e.g. R28/R89
<naobsd>
it was a easy bug
<AstralixNB>
I am only talking of 30xx to 31xx
<naobsd>
and old loader can be used/avaiable
<naobsd>
ah
<naobsd>
very few device uses u-boot
<AstralixNB>
I never had any device older than 2918
<naobsd>
I'm talking about RK30xx/RK31xx
<linuxium>
toshiba a10 is one of the few I knew of
<naobsd>
e.g. ASUS MeMO Pad 8
<AstralixNB>
correct
<naobsd>
people believes RK3188 cannot be bricked
<naobsd>
so some guy tried to flash RK proprietary loader for NAND
<naobsd>
fortunately, I have u-boot binary for ASUS MeMO Pad 8 extracted from backup partition on MeMO Pad 8
<AstralixNB>
but what exact loader did he flash?
<naobsd>
it could be unbricked
<AstralixNB>
ok, wait
<naobsd>
random loader(firmware) for random RK3188 devices which uses NAND and RK proprietary loader
<naobsd>
again, people believe any loader binary can work on any RK3188
<AstralixNB>
if you have a hardware that is not supported by the loader, e.g. DRAM or NAND chips without any support by RK-Loader, then the MASK-ROM starts Loader and Loader fails to work
<AstralixNB>
In that case you have a brick
<naobsd>
and probably some people believe any random firmware for RK3188 can work on any RK3188 device
<naobsd>
AstralixNB: now you understand what I said some minutes ago
<naobsd>
if you flashed random loader, it may be bricked
<AstralixNB>
That is not correct as you need to verify if your chips are supported
<naobsd>
I'm talking about random people who don't very anything
<AstralixNB>
Unfortunately Version 1 loaders where more failsafe as they often tried to stay in USB connection as long as they could.
<AstralixNB>
Version 2 Loaders often ran into failure conditions where they just stop working
<naobsd>
please understand there is possibility
<AstralixNB>
right, I have to agree
<naobsd>
flashing random loader shouldn't be recommended without warning
<linuxium>
so is the SHA Error or CRC Error coming from the bl then?
<AstralixNB>
yes
dlezcano has quit [Ping timeout: 264 seconds]
<AstralixNB>
but I reflashed back to original loader provided with the original image of the tablet
<AstralixNB>
same result
<naobsd>
otherwise very few unlucky people ask me "please tell me how to unbrick" :(
<linuxium>
just the loader or ramdisk and kernel as well?
<AstralixNB>
there are so many pages describing how to unbrick
<naobsd>
(I'm not universal too)
<linuxium>
RTFM v2.0 = google
dlezcano has joined #linux-rockchip
<AstralixNB>
linuxium, the Loader says this
<naobsd>
AstralixNB: all of them said "flash this loader, if it doesn't work, try another one. don't worry, RK is unbrickable!"
<AstralixNB>
here you can see some trials booting from NAND or SD
<naobsd>
it makes people flash random loader without care :(
<AstralixNB>
yes.
<AstralixNB>
Ok, let's take it like this: If you're normal user, avoid flashing Loaders, if you're an expert with some hardware skills, it is unbrickable
<linuxium>
that is not picking up anything
<AstralixNB>
??
<naobsd>
even if expert, if very special loader is required and not available on the net, it's brickable
<naobsd>
then, expert will try to write working loader
<AstralixNB>
unlikely but possible. But as an exoert you should consider to dump the loader before flashing a new one.
<naobsd>
no problem :)
<naobsd>
we know IDB layout
<naobsd>
dump loader from IDB should be possible
<AstralixNB>
however, if we extend the work on "boot everything from SD", this flashing and killing NAND will not be needed anymore
<linuxium>
it is like partition / parameter mismatch
<AstralixNB>
linuxium, I flashed the original firmware delivered by the manufacturer
dlezcano has quit [Ping timeout: 264 seconds]
<naobsd>
so only I can guess is hardware problem...
<AstralixNB>
And I flashed two different flavours of Omnirom that I had running on the device for weeks
<linuxium>
maybe, but that is not what your error is saying
<AstralixNB>
RK confirmed high chance for defective DRAM
<AstralixNB>
Image is loaded to DRAM and fails CRC or SHA checksum.
<AstralixNB>
This onyl can happen if the image on NAND or copy in RAM is defective
<AstralixNB>
But if you load different images from SD and NAND and you always get CRC or SHA error, the only common place is the DRAM
<AstralixNB>
however if you have a different idea... I am open for anthing
<AstralixNB>
I still have a few weeks of warranty as the MB has been exchanged 6 weeks ago cause of a dead flash
<naobsd>
bake it ;)
dlezcano has joined #linux-rockchip
<AstralixNB>
As the loader runs from DDR too, it should not be an electrical problem
<AstralixNB>
It is looking like a defective block somewhere inside... I donÄt know if uboot has an option to memory-test
<AstralixNB>
And in this tablet DRAM is under a metal shield that is soldered to the pcb too
<mrcan>
naobsd: i have trouble about loading mali driver. if you have time, may you help?
levd has quit [Ping timeout: 264 seconds]
<linuxium>
I've seen this error before, and it has always been around parameter definition, syntax or location, format/definition/workability of boot.img and kernel.img .. you are basically not booting so I'd initially suggest the kernel.img is not correct
<linuxium>
and ... just because it has happened to me .. you know that the 'original firmware delivered by the manufacturer' works?
<naobsd>
AstralixNB: oh, it's time to make our own DDR init blob with memory test... ;)
<mrcan>
compiled kernel modules (drm.ko mali_drm.ko ump.ko), copied them to /lib/modules/3.0.36+/ also installed libUMP xutils-dev libx11-dev libxext-dev libdrm-dev packages for dependencies.
<naobsd>
mrcan: please tell detail
<AstralixNB>
I have no reply from the vendor yet, so I have some time to try... However, even I flashed files that I didn't touch at all preoduce this error
<naobsd>
AstralixNB: how about reading back flashed images via usb and compare them?
<linuxium>
AstralixNB: are you flashing an image or components as in loader, boot, kernel, et al?
<AstralixNB>
yep, I note that idea...
<mrcan>
my linaro package is nano, not alip
<AstralixNB>
Unfortunately the images are only available as a multipart-image (rockdev/Images/*.img)
<naobsd>
mrcan: please tell me _detail_
<naobsd>
mrcan: e.g. dmesg around insmod
<mrcan>
insmod /lib/modules/3.0.36+/mali.ko
<mrcan>
Error: could not insert module /lib/modules/3.0.36+/mali.ko: Unknown symbol in module
dlezcano has joined #linux-rockchip
<linuxium>
AstralixNB: so why not unpack it?
<AstralixNB>
??
<AstralixNB>
It is unpacked
<AstralixNB>
I have no upgrade.img
c0d3z3r0 has quit [Ping timeout: 256 seconds]
<naobsd>
mrcan: _detail_ please
<naobsd>
mrcan: run dmesg command
<mrcan>
naobsd: okay sorry im on it
<linuxium>
sorry, what does multipart-image mean?
<naobsd>
packed or unpacked has no relation to boot problem
<AstralixNB>
You have a directoy with separate kernel.img, misc.img, boot.img, recovery.img and system.img
c0d3z3r0 has joined #linux-rockchip
<AstralixNB>
normally not.
<AstralixNB>
and the vendor image was a unmodified zipped file. I unpacked it and flashed it.
<linuxium>
okay, so you flash as 'rom.img' or whatever, or individually as 'kernel.img' 'boot.img' etc?
<AstralixNB>
for this tablet only individual images are available
<linuxium>
meaning then you have to 'flash' the 'parameter' then?
<AstralixNB>
yes
<AstralixNB>
I flashed the unmodified OEM parameter file
<naobsd>
flashing tool doesn't flash packed image as is. flashing tool reads each image from packed image and flash them individually
<AstralixNB>
ll
<AstralixNB>
ups
<linuxium>
and the tool use use to flash?
<AstralixNB>
upgrade_tool for linux or the usual windows tool
<AstralixNB>
doesn't change anything
<AstralixNB>
Upgrade Tool ver 1.21
<linuxium>
so (in linux) upgrade_tool -ef ...then
<AstralixNB>
Windows: RKDevelopTool_v1.37
<linuxium>
upgrade_tool -p <yada>
<naobsd>
AstralixNB: SD boot is also failed, right? and you made bootable SD with dd or something (it's not upgrade_tool and not windows flashing tool)
<linuxium>
update_tool -b <yada>
<linuxium>
etc?
<AstralixNB>
linuxium, I know the full features of the upgrade_tool
<naobsd>
image format and kind of tool shouldn't be a problem
<AstralixNB>
And I used the full set of instruments
<AstralixNB>
I even used a loader that recovers any shot BBT on the flash
<AstralixNB>
so yes, I flashed parameter, kernel, boot recover by upgrade_tool -p,k,b,r,etc <image>
<linuxium>
AstralixNB: I'm not questioning your knowledge but what you have done so I can compare with my own experience
<AstralixNB>
For upgrading loader I did ef, ul, lf
<AstralixNB>
linuxium, yes. You're right, it is always good to follow all steps again and see what has been missed out. We say "4 eyes see more than 2 eyes"
<naobsd>
mrcan: when/how/what did you run insmod? I cannot find any sign from your dmesg
<mrcan>
after boot i run insmod on console
<AstralixNB>
But I exactly followed the steps and I even used a little script that does all steps automatically. This script was used to test OmniROM on the tablet with 1.24 and 2.16 loaders
<mrcan>
i got dmesg output after enter insmod
<AstralixNB>
I even used linux and windows tools to flash 3 different images that where know to work.
<naobsd>
mrcan: you only run insmod with mali.ko?
<linuxium>
okay, here is a difference, I always use ef then uf ... but first you have to use afptool and rkImageMaker to create an image ... why ... because of undocumented problems in the past
<mrcan>
compiled kernel modules (drm.ko mali_drm.ko ump.ko), copied them to /lib/modules/3.0.36+/ then boot system and entered insmod
<mrcan>
did i wrong anything?
<naobsd>
mrcan: please write _detail_ as much as possible. what module you tried to insmod?
<naobsd>
only mali.ko?
<mrcan>
yes only mali.ko
<AstralixNB>
but the uf command only automatically does the ef, ul, lf, di.... sequence by just one user-call
<naobsd>
wrong
<naobsd>
load drm, mali_drm, ump, then mali
<naobsd>
actually I cannot remember dependency now
<naobsd>
but there is dependency between modules
<linuxium>
mrcan: Unknown symbol in module ... was the module compiled with the kernel you are using?
<linuxium>
AstralixNB: and performs an element of error checking
<AstralixNB>
hmm... if the images on my drives are defective, the mkimage will pack and sign these, loading them into the unit and then?...
<AstralixNB>
btw the upgrade_tool is doing a read-compare after writing
naobsd has joined #linux-rockchip
dlezcano has quit [Ping timeout: 244 seconds]
<linuxium>
nest step: confirm each flashable component fits within the allocated size (i.e. if boot.img is 14MB and is being flashed into a 8MG space, as defined by parameter), then you'll see no flashing errors just failure to boot
cnxsoft1 has quit [Ping timeout: 272 seconds]
<linuxium>
s/MG/MB/p
<naobsd>
I have no idea if your working(worked) images are defective.... ;)
<naobsd>
mrcan: all I can say is it's loaded
<AstralixNB>
linuxium... the images I flash have already worked for weeks
<mrcan>
naobsd: thanks a lot! i will try how its accelarating.
<naobsd>
I cannot test anything not in front of me
dlezcano has joined #linux-rockchip
<AstralixNB>
They are taken out of the my firmware-archive
<naobsd>
please try 1st, if it doesn't work, please tell detail
<mrcan>
okay naobsd thanks again
GriefNorth has quit [Ping timeout: 255 seconds]
<AstralixNB>
Anyhow, thanks a lot for your help... I have to do some work now and be back later. May be I give it another try tonight.
<linuxium>
AstralixNB: but they don't work now? so if they don't work now and if you tested the 'backups' originally to ensure a restore worked and you haven't modified or altered the h/w then send the device back with h/w failure, otherwise you are asking us to solve a hardware problem through observations and occasional logs which may only be appropriate once other factors have been ruled out.
linuxium has quit []
<AstralixNB>
Early this day I wrote: (13:34:28) AstralixNB: My tablet just tells SHA Error or CRC Error regardless if I boot from SD or NAND. So DRAM must be dead
<AstralixNB>
And naobsd confirmed a high posibility that DRAM or SOC have a problem
<mrcan>
naobsd: i tried to compile sunxi-mali repo for test.c. but i got error when trying make config on repo-> Error: Failed to open /dev/mali: No such device
<mrcan>
, also modprobe mali module mali not found. but lsmod shows mali loaded
<AstralixNB>
loading several known-to-have-worked images from different sources via different media (NAND / SD) resulting in same error will most likely reduce the error to only a few parts. One is DRAM as this is as common used regardless of the source of the image, as well as the SOC itself.#
<AstralixNB>
And with using the well known to work linux tool as well as the known to work Windows too with same results, we can exclude these too.
linuxium has joined #linux-rockchip
<AstralixNB>
So there are two options now. The vendor again replaces the PCB or I won a nice screen for my rock1
dlezcano has quit [Ping timeout: 256 seconds]
<naobsd>
mrcan: please make /dev/mali
<mrcan>
emtpy file?
dlezcano has joined #linux-rockchip
<mrcan>
you mean touch /dev/mali?
<naobsd>
/dev/* is not regular file....
<naobsd>
well
<naobsd>
I cannot remember why you don't use prebuilt image which supports mali
<mrcan>
i added /etc/udev/rules.d/50-mali.rules > KERNEL=="mali", MODE="0660", GROUP="video"
<mrcan>
KERNEL=="ump", MODE="0660", GROUP="video"
<mrcan>
is that related with /dev/mali?
<naobsd>
yes and no
<mrcan>
i need custom rootfs and kernel
<mrcan>
haha
<naobsd>
device node should be prepared automatically on most distro
<naobsd>
I don't know what you're using
<mrcan>
i have linaro rootfs and stable 3.0 linux-rockchip kernel
<naobsd>
are you sure there is no error when modules are loaded
<mrcan>
he added parameters to make config VERSION=r3p2-01rel1 ABI=armhf
<linuxium>
AstralixNB: I hope it works out for you. I just spent the last two month looking at messages like yours with my Orion R28 and was lucky in trying alternatives I finally found one that worked. It is funny as even Tronsmart told me to give up!
linuxium has quit [Quit: Page closed]
<mrcan>
naobsd: i compiled with using that parameter. but i dont understant why i cant see modprobe mali
<naobsd>
mrcan: how did you confirm "no error"?
<naobsd>
any detail?
<naobsd>
if everything fine but /dev/mali /dev/ump is missing, please make them with mknod command
bengal has quit [Read error: Connection reset by peer]
bengal has joined #linux-rockchip
<hramrach_>
does nobody build the rk kernel in separate directory?
c0d3z3r0 has quit [Ping timeout: 240 seconds]
c0d3z3r0 has joined #linux-rockchip
<rperier>
both marsboard and RR are unable to boot from usb or from the network, and ethernet is done
<rperier>
so it seems to be a common issue shared by RK3066 and RK3188, I will look at recent changes on mainline for: dts, pinctrl, clk, mach-rockchip and I will try to investigate
nighty-_ has quit [Quit: Disappears in a puff of smoke]
<field^Mop>
there's always a chance to zap cpu or nand/dram when handling a bare device. static discharges may kill the chips, even if you don't notice anything when it happens.
<field^Mop>
symptoms may very well be systematic errors, like Astralix1 sha1 crc errs.
<field^Mop>
thats why i solder two wires and a button to the reset/recovery mode/rom mode pins.
<field^Mop>
naobsd: i still cannot understand how it should be possible to brick a rk31xx device by flashing nonsense to nand.
<field^Mop>
naobsd: iff there are mask rom pins you can access and replace the faulty binary.
<field^Mop>
naobsd: btw, it is radxa who is telling "any-flashers" that the rk3188 cannot be bricked. maybe that very statement should be removed?
<field^Mop>
Astralix1: do you use the correct tool to rkcrc the images?
<field^Mop>
Astralix1: what part of code is printing the invalid tag stuff?
nighty-_ has joined #linux-rockchip
<field^Mop>
Astralix1: obviously the loader does disagree with the sha1 of the code it tried to execute
nighty-_ has quit [Read error: Connection reset by peer]
<field^Mop>
Astralix1: so this is where i'd investigate freely in any direction.
<field^Mop>
Astralix1: something has changed. maybe even unnoticed
<field^Mop>
Astralix1: (or you zapped a chip by ESD)
eebrah_ has joined #linux-rockchip
<field^Mop>
Astralix1: you could write your own memtest
<field^Mop>
Astralix1: or just desolder that dram and replace it by some known good part
RayFlower has joined #linux-rockchip
RayFlower has quit [Quit: minab476vw3 tedgfjkhjl,kyjtrheg6s]
hramrach_ has quit [Remote host closed the connection]
hramrach_ has joined #linux-rockchip
RayFlower has joined #linux-rockchip
bengal has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
naobsd has quit [Quit: Page closed]
gb_master has joined #linux-rockchip
bengal has quit [Quit: Leaving]
gb_master has quit [Remote host closed the connection]
RayFlower has quit [Read error: Connection reset by peer]