RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 264 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
antoinemaillard has joined #linux-rockchip
<Tony_>
I know how the POWER key resume the system. it has a IRQ GPIO alone. but the remote control is that some keys shared only one IRQ GPIO.
<Tony_>
I think it's impossible to resume by IR when it's "hibernation"(deepest suspend) now.
<Tony_>
maybe it's a good way that don't let OS deepest suspend. actually, TV-BOX must have this problem. I don't have this device around me.
<naobsd>
what's the problem? if SoC can wake IRQ from any gpio, input from gpio remote will work
<naobsd>
if you want to identify remote vendor/key code, some code is needed in sram(I'm not sure it's possible on RK3188), but it's another issue ;)
<Tony_>
for what's the problem. the problem is that there is a POWER key on IR too. press this key can't wakeup system when the system is suspend.
<Tony_>
The IR driver was from RK.
<Tony_>
It can works fine(suspend or resume) when early suspend.
<rperier>
hi guys
<Tony_>
naobsd, is that clear ? ;)
<Tony_>
rperier, hi.
RayFlower has quit [Read error: Connection reset by peer]
AstralixNB has joined #linux-rockchip
RayFlower has joined #linux-rockchip
<Tony_>
for "if SoC can wake IRQ from any gpio, input from gpio remote will work", yes. you are right. but there many keys on IR. I just want to the "POWER" key on it can resume the system.
<Tony_>
like TV's remote.
<naobsd>
Tony_: I think you said IR receiver generate signal while in suspend
<Tony_>
naobsd, almostly.
<rperier>
I was wondering, how could you symbolize "VSYS" in the devicetree ? this is for vcc<N>-supply inputs for tps65910 for the marsboard. I think that regulator-fixed 5V might do the trick but I am not 100% sure (I am searching on google in //)
<naobsd>
if it's possible(I don't know) to decode IR code in suspend, you can detect only POWER key
<naobsd>
I don't know detail about RK3188 suspend
<Tony_>
naobsd, decode IR code failure in suspend. so I can't get any key code.
<rperier>
mhhh regulator-fixed seems to be the right way...
<rperier>
(according to some dts and dtsi files)
<naobsd>
Tony_: what's "decode IR code"? I think driver is not working in deepest suspend
<Tony_>
naobsd, I know _only_ some too.
<naobsd>
you said just "it doesn't work with current code/configuration"?
<Tony_>
naobsd, yes, I think so.
<naobsd>
what I said is _not_ "current code should work"
<Tony_>
I will give you a picture.
<naobsd>
I don't need any info about just "it doesn't work"
<naobsd>
if you tried something new and failed, I want to know what you tried
<naobsd>
if you tried current code and failed, "it doesn't work" is enough
<naobsd>
no need to take a picture
<Tony_>
I just want to say why it doesn't work, and why I said that "decode IR code failure in suspend".
<Tony_>
during it's resuming, time is gone. when the driver of IR resume okay. it can't get a whole IR signal.
<Tony_>
only partly signal, so I said that "decode IR code failure in suspend".
<Tony_>
BTW, maybe I should say "decode IR code failure after resume because the IR driver can only get partly IR signal"
<Tony_>
the reason why IR driver can only get partly IR signal is the first part signal is gone during resuming time.
levd1 has joined #linux-rockchip
<Tony_>
That's my point.
levd has quit [Ping timeout: 264 seconds]
<Tony_>
then IR driver can't get a correct key code, so it didn't do anything. then it's suspend again.
<Tony_>
then *kernel suspend again.
<Tony_>
naobsd.
levd has joined #linux-rockchip
<naobsd>
"decode IR code by driver (after wake)" is too late to decide "wake or not by key code"
levd1 has quit [Ping timeout: 244 seconds]
<naobsd>
I guess, generate power key event after resume (regardless of partially received IR signal) solves "kernel suspend again (immediately?)"
<naobsd>
I think you mixed several different issues
<naobsd>
time to return to home...
naobsd has quit [Quit: Page closed]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
<Tony_>
maybe, maybe for my pool English. I like a dumb.
<Tony_>
*poor
<Tony_>
naobsd, I generate power key event after resume can solves "kernel suspend again _immediately_", the OS can be resume successful. BUT ...
<Tony_>
likes TV's remote control, do you want your remote control resume the TV whatever you press any key such as Vol+/- ,menu etc.
<Tony_>
Obviously don't. just want to resume system only by "POWER" key on remote control. So it's a paradox.
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
naobsd has joined #linux-rockchip
<naobsd>
Tony_: I understand what you want
levd1 has joined #linux-rockchip
<naobsd>
and currently I have no idea how to implement it on RK3188
<naobsd>
probably any IR transmitter which uses same freq can wake
<Tony_>
naobsd, i'm really glad you understand. :P
levd has quit [Ping timeout: 272 seconds]
phh has joined #linux-rockchip
<naobsd>
I already said decode IR code in kernel is too late
<naobsd>
please understand
<Tony_>
Yes, I mixed several different issues _before_. ;)
<naobsd>
if
<naobsd>
if resume handler of rk remote driver can run at very first place in whole resume process
<naobsd>
and if handler wait proper key signal (drop partial signal)
<naobsd>
then you can get key code and decide "continue to wake or sleep again"
<naobsd>
then it will be alternative solution
wildea01 has joined #linux-rockchip
<naobsd>
ah, one more if, if remote controller send key code repeatedly while "drop partial signal and wait proper/complete key signal"
<Tony_>
one more if the system is only _early suspend_ don't _suspend_. likes a PC we used.
<Tony_>
then it will be alternative solution too.
<Tony_>
I just confused which way do the android TV-BOX used. maybe I should buy one and figure it out.
<naobsd>
using only early suspend is another solution, yes.
<naobsd>
I'm not sure it's possible w/o external micro controller
<Tony_>
I'm sorry, I'm not clear about "w/o". write / operate ?
<naobsd>
without
naobsd has quit [Quit: Page closed]
<Tony_>
external micro controller is about IR ? if so, I can tell you it works fine even suspend.
<Tony_>
I can get whole IR signal from GPIO0_A6 of CPU even the system is suspend.
<Tony_>
and the remote controller can works fine when the USB OTG is connected. (I think it's early suspend).
<Tony_>
and the remote control can works fine when the USB OTG is connected. (I think it's early suspend).
levd1 has quit [Ping timeout: 264 seconds]
naobsd has joined #linux-rockchip
<naobsd>
Tony_: I'm talking about your issue, not about early suspend. you said you can get only partial signal
<naobsd>
Tony_: if it works in deep suspend, then you have no problem.
<Tony_>
naobsd, sorry, actually, I just don't understand "external micro controller".
<naobsd>
Tony_: it receives signal, decode key code, then wake CPU
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
<Tony_>
naobsd, got it. it's a way.there are four ways now. ;)
mrcan_ is now known as mrcan
naobsd has quit [Quit: Page closed]
field^Mop has joined #linux-rockchip
<field^Mop>
re
<field^Mop>
does anybody know whether the rk3188 nand images contain oob information or just user data?
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
naobsd has joined #linux-rockchip
field^Mop has quit [Ping timeout: 240 seconds]
<Tony_>
sorry, I just use eMMC not Nand.
linuxium has joined #linux-rockchip
<Tony_>
field^Mop, in my opinion, images contain oob information if it is for Nand.
<naobsd>
linuxium: hi, thank you
<linuxium>
hi everyone
<naobsd>
I hope we can discuss whenever it needs on here :)
<naobsd>
linuxium: your R28 can be unbricked?
<linuxium>
no, I tried RK3288 sdboot tonight but it didn't work ... nothing showed up ... so I tried on my dev board and was going to paste logs as they are interesting
<linuxium>
I modified the parameter file (see http://pastebin.com/SG1PNiKc) so I could see if it was used during sdcard boot ... it was ... see line 'MACHINE_MODEL:naobsd-sdcard-parameter'
<naobsd>
linuxium: it seems parameter is loaded from SD, but something wrong after that...
<linuxium>
so it looks like it sees parameter.img from sd card and resource.img and then fails with 'ERROR: [rk_load_image_from_storage]: bootrk: bad boot or kernel image'
<naobsd>
I think I tested that file... :(
<naobsd>
I'll check it again. and there is newer u-boot, I'll try it too.
<naobsd>
linuxium: I have no idea about your R29, can it go mask rom mode?
<linuxium>
as the error (in the log) was 'load kernel image failed' I tried several kernels that I knew worked on the device (e.g. stock android kernel.img, a working linux kernel.img) etc
<linuxium>
my R28 is permamently stuck in mask rom mode
<naobsd>
linuxium: what happen if you short 2holes for mask rom mode(it should disable eMMC completely) but with bootable SD card in slot?
<naobsd>
(btw I learned how to make complete brick... it's possible ;)
antoinemaillard has quit [Quit: antoinemaillard]
<linuxium>
I haven't tried to short the 2 holes any more after I tried extensively doing that when trying to flash an Android ROM - I find it very difficult to do as I need the help of some to hold a light and magnifying glass otherwise I cannot see what I am doing and I need my two hands to short the pins, hold a stick in for the recovery button and insert the power - I think even for someone with good enough eyesight this is a hard m
<linuxium>
own!
<naobsd>
I think you can insert paper clip to 2 holes, then your hands are free... sorry, I don't know well about 2holes on R28/R89
<naobsd>
anyway
<naobsd>
I just guessed broken eMMC somehow interfere SD boot
<naobsd>
not sure
<naobsd>
linuxium: btw, what's your dev board? you have another rk3288 board?
<linuxium>
firefly
<naobsd>
ah, I see. beta board?
<linuxium>
yes, beta
nighty^ has joined #linux-rockchip
<naobsd>
then, we have same board :)
<naobsd>
I tried SD boot on firefly beta. it should work, but I should check it once more
<linuxium>
LOL, I just noticed a type in my make command ... dd if=kernel.img.img of=${DEV} ... no wonder it didn't work ... and these are new glasses
<linuxium>
I'll go and fix and try again
<naobsd>
I see
<naobsd>
there is one another caveat,
<naobsd>
when SD booting, if there is eMMC, partitioning (defined in parameter on SD) is applied to eMMC, not SD card ;)
eebrah has quit [Remote host closed the connection]
eebrah_ has joined #linux-rockchip
<naobsd>
but it's done in kernel, we have source, we can change behavior
<naobsd>
anyway, booting from SD is not so useful on eMMC device
Isaac has joined #linux-rockchip
<Isaac>
Hey,
<naobsd>
hi
<Isaac>
I am looking for a way to identify my Radxa boards uniquely
<Isaac>
Hi naobsd. I've seen some conversation on IRC about MAC, eFuse bits, etc
<naobsd>
Isaac: as far as I know, only MAC for wifi is unique
<Isaac>
I was wondering what is 256 bits of eFuse is actually for? Is it filled with randomly for each board?
<naobsd>
Isaac: I guess it's empty
<naobsd>
Isaac: not sure. I never tried to use efuse
<Isaac>
Really? Then Rockchip has shipped RK3188 with eFuse for future use? Is there any documentation on the programming?
<naobsd>
I just said about Radxa Rock, not Rockchip
<naobsd>
and just guessed
<Isaac>
I know. It would be great if you include some hardware unique identification to the Rock2
<naobsd>
I'm not Radxa person
<naobsd>
"I just guessed"
<Isaac>
Ah. I've seen you active on the radxa forum and just assumed you are.
<naobsd>
I think you can put serial number and MAC addresses into IDB as like as some factory does
<naobsd>
but you have to do it on every board, then you may do similar thing in parameter or anywhere else
<Isaac>
Is IDB a part of NAND? Can it be copied using a rkflashtool or something else?
<Isaac>
It would be fine even I have to do it on every board. It just has to be (very) hard to copy on another board.
<naobsd>
UpgradeDllTool
<naobsd>
I never tried it myself
<naobsd>
Tony_: do you know about UpgradeDllTool?
<naobsd>
Tony_: especially "how to use"
<Isaac>
naobsd: seems promising. Hope accessing the serial number would not not hard in userspace
<Isaac>
AstralixNB: Thanks. I am looking for a way that prevent faking the "unique id". The problem with the MAC is that the user can change the mac address easily.
<AstralixNB>
until you make use of lockbits and secure boot you will never prohibit this case
<naobsd>
Isaac: ah, if you can change serial etc by UpgradeDllTool, user can do it too...
<AstralixNB>
No you can't
<AstralixNB>
It is a minute of work to get a kernel with a faked MAC and a self made USB VID
<Isaac>
naobsd: Yeah that's correct. It's just more hard and "obscure" to copy it.
<naobsd>
there is secure boot and drm key box
<Isaac>
AstralixNB: The lockbits is about the eFuse bits in Rockhip?
<AstralixNB>
Isaac, that is another thing. If you want to identify original and faked boards, that where sent to you for repair, then you will probably able to dientify them by uniquie sereial numbers or programmed ID bits.
<AstralixNB>
But you will not be able to identify these boards over the network
<Tony_>
naobsd, there is a Chinese document about how to use UpgradeDllTool.
<Isaac>
AstralixNB: That's fine. Are programmed bits accessible in userspace?
<Tony_>
I read it, it say that UpgradeDllTool is used to flash MAC addr into Eth IC.
<AstralixNB>
You will probably have to write a simple kernel driver propagating that addresses of the fuses to the userspace
<AstralixNB>
But it is a simple fuse-field of 32x32 bits
<naobsd>
there is no discrete ethernet ic, no eeprom for it
<Isaac>
Tony_: Thanks. I've read it too. The doc doesn't talk about flashing a serial number of somethng, but the UpgradeDllTool does provide such interface
<Isaac>
Which tool can flash to fuse field? I guess it needs some custom electrical voltage too, right?
<naobsd>
RK designed to use some IDB area on NAND/SD/eMMC to store such an info and read it from kernel driver
<Tony_>
fuse ? I have learn about it. at that time I need a UUID of RK3188.
<AstralixNB>
Isaac, I am not sure if you will be able to use this fuses without applying for an NDA and some support from RK
<naobsd>
as far as I know, efuse is used only to identify RK3188 or RK3188T in kernel
<Tony_>
RK gave me a patch, I can get serial of eFuse.
<Isaac>
Tony_: Yes. One option seems to be using fusebit as a unique ID
<Tony_>
But they were kidding me. all the UUID is same one.
<AstralixNB>
:)
<Isaac>
AstralixNB: Even if the fusebits are filled with random data that would be fine for me, as I can read them as being a unique identifier.
<Isaac>
Tony_: Ah :
<AstralixNB>
Yes, but if the random data is the same on all chips sold...
<Tony_>
finally, I use the UUID of eMMC.
<naobsd>
there is SecureBootTool_v1.51.rar under RKDocs/common/drm/widevine in RK3188 4.4.2 SDK
<Isaac>
Tony_: Well that would be good too, as far as UUID be unique. Do you have docs on that?
GriefNorth has quit [Quit: WeeChat 1.0.1]
<Isaac>
naobsd: Well thanks. I don't know about how secureboot works. I will take a look at that if efuse/emmc failed.
<Isaac>
AstralixNB: Yeah, that kills the purpose.
<Tony_>
what ?
<Tony_>
Isaac, about what ? eMMC ?
<Isaac>
Rockchip is not great at software support (e.g. We are stuck at kernel 3.0.35 because of that NAND driver).
<naobsd>
we can ignore NAND
<Isaac>
It would be really great if Rock2 includes some hardware with unique id.
<Isaac>
Tony_: You was talking about using UUID of eMMC as a serial number right?
<Tony_>
Yep.
<AstralixNB>
I would rely on the eMMC serial code as these are often assembled by year, week, wafer number, chip x/y coordinate on that wafer. So the serial code is truly unique over the next 100 years :)
<Tony_>
Isaac, run cmd "cat /proc/emmc_info ".
<Isaac>
naobsd: In some application yes, we can ignore NAND. But in some others, like our product, we actually can't.
<Isaac>
naobsd: Some guy was working on the NAND driver. Was that you? I hope someday we have that too and we switch to kernel 3.10 or something.
<Isaac>
AstralixNB: Well that would be great!
<Tony_>
you will see UUID of eMMC.
<Isaac>
AstralixNB, Tony_: I don't currently have Rock2 on my side to check this, I have to wait for a few hours.
<Isaac>
* Rock Pro
* hramrach_
has a rockpro
<naobsd>
linuxium: my u-boot should say "U-Boot 2014.10-RK3288-02-gd08e24a (Nov 11 2014 - 13:08:51)"
<AstralixNB>
I only have preview rocks here
<hramrach_>
finally the package with it was found, heh
<Tony_>
Isaac, okay, if you want to learn there are a link.
<hramrach_>
does it have emmc? the chip on top looks like plain flash to me
<Isaac>
Tony_: Thanks Tony! Have a good day
<Isaac>
It says "cat: /proc/emmc_info: No such file or directory"
<naobsd>
all RR uses NAND
Tony_ has quit [Read error: Connection reset by peer]
antoinemaillard has joined #linux-rockchip
<Isaac>
I guess I have to reconfigure my kernel right? to enable emmc driver
<naobsd>
ah, sorry, except Lite2014 ;)
<hramrach_>
yes, some chip from Micron here
<naobsd>
Isaac: there is no eMMC on RR
<AstralixNB>
the big firewall works. I am restricted from access to that link...
<naobsd>
Tony and AstralixNB just said about eMMC
<AstralixNB>
right
<naobsd>
not RR
<Isaac>
naobsd: Ah. :(
<AstralixNB>
Normally a NAND has a serial number too, but AFAIK the rknand driver does not publish this... let me check...
<hramrach_>
anybody working on a MTD driver?
<AstralixNB>
yes, from time to time
<hramrach_>
how far did it get?
<AstralixNB>
Actually waiting for input from RK
<hramrach_>
hmm
<AstralixNB>
Feeling a bit like Nr. 5... Need input...
<hramrach_>
what is the issue?
dlezcano has quit [Ping timeout: 272 seconds]
<AstralixNB>
Isaac, booting from SD will not give much information on the used card. If you boot from NAND, the "cat /proc/rknand" will give a lot more information. You should check if it provides a serial number.
<AstralixNB>
hramrach_ I was waiting for other mainliners to get alle the clocks set up fine to access the interface. Then I sent a bunch of questions to RK but got only a new rknand driver in my inbox. So I postponed this work a bit for supporting some guys with their new RK3288 hardware
<Isaac>
AstralixNB: Thanks. There is a "FLASH ID: 4b44642c" in the output of /proc/rknand. I have to check if that's unique
<AstralixNB>
That is the flash id, the verndor specific part number
<AstralixNB>
So with this you see it is a vendorx, chip y, but it is the same for all of these chips
eebrah_ has quit [Quit: leaving]
<AstralixNB>
hramrach_ Last week I was thinking about a simple NAND interface driver sufficient for using ubifs on top of it?
<Isaac>
AstralixNB: Oh I see. The other outputs seems to be various usage statistics
<AstralixNB>
yes.
<Isaac>
AstralixNB: I try to look more into it, maybe there is some uniqueness can be derived from that output
<AstralixNB>
Isaac: Let us know if you find something useful.
<AstralixNB>
guys, need to step into background again. See you later this day
<AstralixNB>
Isaac, welcomed.
cnxsoft has quit [Quit: cnxsoft]
dlezcano has joined #linux-rockchip
<field^Mop>
Isaac: i plan on r-e the nand on rr pro/rk3188
<field^Mop>
Isaac: but haven't got any device yet
<field^Mop>
*waiting. like AstralixNB *need input
<hramrach_>
you have some idea how to do it?
<hramrach_>
because I don't even have any idea how to re an i2c touchscreen :/
<AstralixNB>
field^Mop, we should coordinate that work. The problem is probably not the interface of the SOC but the FTL. So I thought it is more easy to provide a non-FTL interface and let ubi do the rest without having trouble with software patents
<hramrach_>
or rather let ubi deal with the trouble
<hramrach_>
to have fully working bootable nand you need to deal with the bootloader reserved area
<AstralixNB>
hramrach_ what trouble with your touch?
<AstralixNB>
hrmarach_ no, if the simple NAND interface works, ubi will work and uboot can handle ubi
<hramrach_>
I have like 3 tablets with a gsl touchscreen
<hramrach_>
and none works in linux
<hramrach_>
there is a re drive which is supposed to work provided a correct 'firmware'
<hramrach_>
according to the silead datasheet the 'firmware' is probably settings for the touch interface
<hramrach_>
it allows software muxing the touch wires for one so you can design the pcb conveniently and swap the wires in software
<hramrach_>
and other parameters
<Isaac>
field^Mop: Well this is getting complicated for me. I just hope the nand driver will be available for a more recent kernel too. :)
<AstralixNB>
Yes, I know that ugly firmware/settings binary thing in that touch drivers.
<hramrach_>
if you set it wrong it does not work because touching an area means triggering adjacent sensors which are no longer adjacent with wrong setting
<AstralixNB>
Isaac, if I manage to do it, I try to do it the mainline way.
<hramrach_>
I am not sure if the setting is wron or the driver fails completely
<field^Mop>
AstralixNB: good idea. who has already done some work on nand?
<AstralixNB>
hramrach_ I several times pulled the working binary blob from the binary kernel via disassembly
<AstralixNB>
Cause people just falshed a different kernel that has a more recent but wrong driver binary blob installed
<hramrach_>
I have a tool which the driver developer provide which is supposed to pull firmware from the kernel module
<hramrach_>
it pulls several firmware but none works
<AstralixNB>
The original kernel had only an upgrade function so it did not downgrade the driver chip and the tablet touch was dead
<field^Mop>
AstralixNB: the idea was to get a correct nand image and then extract the data and oob
<AstralixNB>
ah, ok. I did this multiple times just using a disassembler... Nice to see that there is a tool, that doesn't work :)
<field^Mop>
AstralixNB: with this we could try to r-e the ecc algo
<field^Mop>
AstralixNB: so far for the ftl
<hramrach_>
as said I am not sure if the firmware is work or the driver fails in another way. haven't seen it working except in the stock android rom which has very different driver
<field^Mop>
afk
<hramrach_>
*wrong
<AstralixNB>
fiel^Mob, all actual FTL is covered by software patent, while the ECC is known and supported by hardware on the SOC. But I am not sure if they use this hardware.
<naobsd>
raw nand data include oob should be able to read via rockusb protocol
<AstralixNB>
hramrach_ I see what I can get for you. I am waiting for a dev kit that has a screen and touch.
<hramrach_>
but regarding nand you need the area the on-SoC loader reads in the same format regardles of rknand/MTD/...
<hramrach_>
still working as storage only would be nice too
<Isaac>
AstralixNB: Sorry to interrupt. There is a "1021c000-1021ffff : emmc" line in the output of "cat /proc/iomem". Is that something virtual?
<AstralixNB>
naobsd, we are toalking about a driver not USB.
<AstralixNB>
Nor sure if this ins't the linux UUID
<naobsd>
AstralixNB: sorry, my message was for field^Mop, he want "data and oob"
<hramrach_>
AstralixNB: reading the raw data over USB might be helpful to verify that the driver gives same, though
<mmind00>
Isaac: that is the emmc controller @0x1021c000
<AstralixNB>
And not sure how unique this one is. Cause it is generated one time and then written to the filesystem
<AstralixNB>
Ah! fast eye! naobsd, that is the address if the controller in the virtual memory space.
<hramrach_>
AstralixNB: problem with touch on tablet is I cannot really intercept the data sent to the controller except by hacking the kernel included in the original kernel somehow
<AstralixNB>
mmin00? Sorry, now it is getting crowdy in here :)
<naobsd>
AstralixNB: about address is for Isaac and mmind00 :D
<naobsd>
yup
<naobsd>
better than silence ;)
<AstralixNB>
absolutely right!
<Isaac>
naobsd, AstralixNB: So, can it contain something as UUID? Or I am just being clueless about what UUID of eMMC is? :)
<AstralixNB>
hramrach_ most chips have a MCS51 uC inside that is bundled with some flash memory. The firmware is only written to it, in case the current version provided by the blob is newer or the checksum is wrong.
<rperier>
naobsd: btw, my leds-gpio patch is merged, so you can rebase your patch on mine and send it
<rperier>
(default-trigger stuffs)
<AstralixNB>
hello rperier
<naobsd>
Isaac: as long as you're using RR, you cannot get any info from eMMC
<naobsd>
rperier: yes, I saw that mail, thanks
<rperier>
AstralixNB: hi :)
<naobsd>
rperier: my work will be delayed, I'm busy to try some SD boot things
<AstralixNB>
trying to into background again :)
<rperier>
naobsd: ok np
<AstralixNB>
cu later
<hramrach_>
see you :)
<hramrach_>
I am quite sure I have a Silead GSL1680 and that the 'firmware' has to be uploaded every time or the chip won't work.
<hramrach_>
but it's probably sensor settings rather than the chip firmware what is uploade
<naobsd>
oh I didn't know that upgrade_tool di can find partition by name from flashed parameter
field^Mop has quit [Ping timeout: 264 seconds]
<naobsd>
upgrade_tool di hoge ../../firefly/misc.img
<naobsd>
Download hoge start...
<naobsd>
Download image ok.
<naobsd>
I always use rkflashtool for this kind of operation ;)
<naobsd>
I can omit "<"
<naobsd>
but I have to type "di" instead of "w"
<naobsd>
"upgrade_tool" is longer than "rkflashtool"