ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | Wiki at | Logs at
ChiaSmurf has joined #linux-rockchip
ferric has quit [Ping timeout: 245 seconds]
ferric has joined #linux-rockchip
ferric has quit [Ping timeout: 272 seconds]
ferric has joined #linux-rockchip
FightingCat has joined #linux-rockchip
naobsd has quit [Quit: Page closed]
GriefNorth has joined #linux-rockchip
temptwo has joined #linux-rockchip
<temptwo> Hello, all. Would anyone be able to help me with an issue I'm trying to resolve?
<temptwo> I have a set of .img files that I can use with the RockChip Flash Tool, but I'm trying to find information on how to combine all of the .img files into one file for use with the RockChip Batch Tool.
<temptwo> I can use the images I have, and flash the units one at a time (Minix Neo X7 Mini), but I have 80 of them and would like to be able to use the Batch Tool to flash 8 in a batch, since it will be faster. I have searched the forum and google, but come up with references to software that leads to dead ends.
hramrach has quit [Ping timeout: 264 seconds]
hramrach has joined #linux-rockchip
GriefNorth has quit [Quit: WeeChat 1.0]
naobsd has joined #linux-rockchip
GriefNorth has joined #linux-rockchip
<naobsd> temptwo: there are RKImageMaker.exe and AFPTool.exe, official pack/unpack tool
FightingCat has quit [Remote host closed the connection]
hipboi has quit [Ping timeout: 272 seconds]
rperier has quit [Changing host]
rperier has joined #linux-rockchip
<rperier> hi all
<naobsd> zzz
<naobsd> sleepy afternoon
hipboi has joined #linux-rockchip
naobsd has quit [Quit: Page closed]
Firefly-RK3288 has joined #linux-rockchip
nighty^ has joined #linux-rockchip
Firefly-RK3288 has quit [Ping timeout: 246 seconds]
akaizen has quit [Ping timeout: 260 seconds]
bengal has joined #linux-rockchip
naobsd has joined #linux-rockchip
nighty^ has quit [Ping timeout: 272 seconds]
nighty^ has joined #linux-rockchip
bengal has quit [Quit: Leaving]
<naobsd> well
<naobsd> git mirrors are almost running...
<naobsd> I need to wait 5 days for DNS :(
<naobsd> let's do wiki thing for next
naobsd has quit [Quit: Page closed]
FreezingCold has quit [Ping timeout: 246 seconds]
FreezingCold has joined #linux-rockchip
architekt has quit [Ping timeout: 260 seconds]
architekt has joined #linux-rockchip
GriefNorth has quit [Ping timeout: 272 seconds]
amstan has quit [Ping timeout: 245 seconds]
amstan has joined #linux-rockchip
AstralixNB has joined #linux-rockchip
akaizen has joined #linux-rockchip
naobsd has joined #linux-rockchip
<temptwo> naobsd: Where can I locate these? I tried hunting down AFPTool, but was unable to find a link anywhere on the forums, and evidently my google-fu was weak, yesterday.
<AstralixNB> Try my ones:
<naobsd> temptwo: there is included in Rockchip's SDK (at least)
<naobsd> oops, they are...
<naobsd> I'm in train, I cannot help now
<temptwo> naobsd: That's okay. If you can let me know when you have a little time free, I really appreciate it. I'm looking at two different github resources, and a couple of links on other forums, to find the files so I can test.
<naobsd> temptwo: which OS are you using?
<AstralixNB> temptwo, I do not have all the backlog, what exactly are you searching?
<temptwo> I have a Windows desktop, and Linux VM.
<AstralixNB> Sowrong way around :)
<naobsd> he want to use batch tool to flash many devices at once
<temptwo> AstralixNB: I'm trying to take the separate image files and compile into single image to use with RKBatchTool.
<naobsd> so I think official windows tools is better
<AstralixNB> recent linux-update tool is working perfect
<temptwo> As for workstations, corporate environment, so I'm stuck with Windows as Host.
<AstralixNB> and it is more likely script-able
<AstralixNB> It all depends on the VM's USB driver capabilities
<naobsd> AstralixNB: and someone who can do it will not ask anything on here :)
<temptwo> Problem is that I don't have a Linux machine I can hook them all into. Only a VM, and I don't trust the USB linking between Host and VM.
<temptwo> Since I'm new to the creation of compiled .img files, I thought I would check the forums first (no luck), and then I came here.
<temptwo> What I have are the backup.img, system.img, kernel.img, etc.
<AstralixNB> Ok, so for linux you can use the current linux-upgrade tool. I posted it here only a few weeks ago.
<AstralixNB> Just in case you like to try
<AstralixNB> For Windows you have onyl the batch-tool that allows programming of up to 8 devices in a row
<AstralixNB> But that requires that you combine the separate kernel / system / ... into one update.img
<naobsd> I have to leave here now, later
naobsd has quit [Quit: Page closed]
<AstralixNB> There is a plan C i'ver heared of
<AstralixNB> You can prepare SD-Cards that then upgrade / program you devices...
<AstralixNB> But I am waiting for cards to arrive to test that.
<AstralixNB> So, which way do you prefer and what help do you need?
<temptwo> I would prefer to be able to compile all the separate image files into one img for use with RKBatchTool.
<temptwo> It allows for batch programming of up to 8 units. I have 80.
<AstralixNB> Yes, 10 refills and you're done
<AstralixNB> :)
<AstralixNB> So, pull the rk-tool git and make it under linux. I am desparately searching my notes how to use these tools do combine all images into one update.img
<temptwo> Indeed!
* karlp isn't at home unfortunately, my home pc has the repo with the afptools that pakc/unpack
<AstralixNB> It is probably the same repo as I have. It is well spread around the net
<AstralixNB> But I used my one only a few weeks ago to do some NAND testing. So I am pretty sure that it is functional
<AstralixNB> I made a script or doc to not have to memorize each step avery time... I am just searching the scipt now as I reorganized my notebook
<temptwo> Ah, so with that one I can compile into update.img? I'll get the VM fired up and start pulling down git clones, once I finish updating this database. Hooray for responsibilities. >.<
<AstralixNB> yes. This little repo contains the tools to add checksums, copy things together or even unpack and disassemble them back into single images.
<AstralixNB> It also contains all tools to create rootfs images and signing for misc, recovery and such
<AstralixNB> oh, guess I found it...
<karlp> I'd _love_ to see one of the repos of these tools be annoited as "holy" and have everyone point to it,
<karlp> and submit tools that are missing from one repo into the "holy" repo.
<karlp> I've been using as it has had the most updates, and because it's pretty, sometimes,
<karlp> AstralixNB: I see you have commits to a wip branch on crewrktables tree of rkflashtool?
<AstralixNB> I am trying to cleanup a bit
naobsd has joined #linux-rockchip
<AstralixNB> These tools where horribly spread and each repo had other addons or missing things
<AstralixNB> The original rk-tools where only to handle images in any way
<AstralixNB> The option to flash something came in later and I never added it to this rk-tools repo. Cause the rk-tools is pure user driven and "unverified"
<karlp> if you can do the cleanup, that would be super :)
<AstralixNB> sorry
<karlp> you've got a much better feel of which is which :)
<AstralixNB> the flash-tool is user driven
<AstralixNB> and the rk-tools are... well some lines are RK driven
<karlp> well, there's the upgrade_tool binary for linux, isn't that the one that RK people suppoort?
<AstralixNB> But there is no need to use the flash-tool as the original RK linux update tool works fine even with the newes chips and loaders
<karlp> and then "something else" for all user reverese engineered and extra things?
<AstralixNB> yes, upgrade_tool is RK original and I got permission to post it
<karlp> not jsut you, it's in chromeos's repo too
<naobsd> upgrade_tool is included in Rockchip Android SDK
<AstralixNB> yes, but check for a recent version
<karlp> chromeos has 1.17
<naobsd> and there is SDK for RK3288 too
<AstralixNB> that is an old one
<AstralixNB> 1.21 at least
<karlp> newest one I'd seen, 1.16 was very common.
<naobsd> temptwo: btw if you like linux in VM, please use it
<karlp> radxa has 1.16 on their download pages.
<naobsd> 1.16 the one in KK SDK for RK3188
<naobsd> 1.16 is
<AstralixNB> Check the most famous source of RK custom ROMs ;)
<AstralixNB> Had used it with 1.1x and 2.xx Loaders
<temptwo> Someone has been mangling my database. I have to fix it. Again. >.< Back in a bit!
<karlp> what's the most famous source of rk custom roms?
<karlp> crewrktables I guess...
<naobsd> I think they still uses my CWM built for JB... I have no time to make KK ver :(
<AstralixNB> karlp, thanks for the flowers :)
<rperier> mmind00: I am pretty sure that when rk3288 devices will be released and used in the market (with a 100% working linux kernel) the mainline support will decrease (like a lot of soc vendor on mainline). Am I wrong ?
<AstralixNB> lol
<karlp> flowers?
<rperier> mmind00: I am talking about the guys who are payed for this support, not about the community of course
<AstralixNB> That you think of crewrktablets as of the greatest source
<naobsd> decrease?
<karlp> heh, I honestly never look at crewrktables, I just inferred that from your urls and post ;)
<karlp> I found the crewrktablets forums and repos to be either out of date, or focused on custom roms for android, which doesn't interest me in the least :)
<rperier> naobsd: reduce sorry, I meant reduce
<AstralixNB> rperier, naobsd, it is very obvious that companies in a less- or low-cost market only focus on one current project.
<AstralixNB> And the past has proved that, but not only RK but MTK and others too
<rperier> yeah not only for RK I agree
<rperier> yeah but these companies could send support and fixes periodically on mainline, and not only when they are interested :/
<AstralixNB> As soon one SOC is established at the market, all teams switch to next generation. It sometimes even ends, that the OEMs have to fix the bugs of the SOC...
<naobsd> many devices in market is cheap one,
<naobsd> it will not 100% work,
<naobsd> and no kernel source.
<naobsd> and many users will ask "how to run Linux on my device!?"
<ssvb> is there a public documentation for RK3288?
<naobsd> technically, it will work, but people will say "it's not perfect!" etc
<AstralixNB> There is a TRM for the 3288 out in the wild?
<naobsd> ssvb: only datasheet? I saw 2 datasheet (same version 1.0 but different date)
<AstralixNB> naobsd, size of these docs?
<naobsd> it's not TRM of course
<rperier> the documentation of the rock2 is already available ? :|
<rperier> nice
<AstralixNB> Ah, ok. So nothing you can use to build your own kernel or hardware
<AstralixNB> The TRM is 10x the size of this overview
<naobsd> no, it's not doc about rock2
<naobsd> I'm talking about RK3288 datasheet
<naobsd> fortunately I could modify kernel source from firefly SDK for my rk3288 box
<naobsd> I can build my own kernel
<AstralixNB> naobsd, this is the tech-spec excerpt from the original TRM.
<AstralixNB> It is enough to solder the chip to a board and probably getting it to run
<mmind00> rperier: I'm not sure I understand what you mean ... to support a new device you only need a separate dts
<naobsd> we can get dts from dtb in resource partition on rk3288
<naobsd> and surprise "why this pin is assigned to this unit!?!?!"
<mmind00> naobsd: that won't help you at all :-)
<AstralixNB> naobsd, we found ou the same on a brand new rk3288 tablet. Some pins are assigned that physically do not exist
<naobsd> fortunately I can restore working code from dtb and dmesg :)
<AstralixNB> naobsd, if you can do that, I send you that for my 3066 tablet :)
<karlp> you have a dtb for that 3066 table?
<naobsd> AstralixNB: I'm talking about rk3288 box :)
<AstralixNB> It is the only device I ever saw using the PWM DC/DC functions of the 3066 SOC
<AstralixNB> sure, I know. I was just kidding
<AstralixNB> I got the frequency/voltage tables with the help of some well known disassembler...
<naobsd> AstralixNB: if you can send rk3288 box, I can be serious :)
<rperier> mmind00: that's not what I am talking about. I am talking about the fact that when rk3288 devices will be available in the market (when rk3288 products will be finished). The support for this SoC on mainline will reduces, because engineers who work on this SoC will switch on the next SoC generation or to another vendor
<mmind00> "engineers who work on this soc" are Rockchip employees ... I don't think they'll switch to another vendor ;-)
<rperier> and google ?
<naobsd> I guess non-rockchip people will not switch so quickly
<AstralixNB> naobsd, yes reading dts/dtb is not an issue.
<AstralixNB> However, 99% od the peoples tasks will switch to the new SOC and the community will have to take care, that older chips still profit from the new code, even if the IPs of the SOC are (mostly) the same.
<rperier> mmind00: no... full time kernel engineers who submit patches last days.
<rperier> (I did not check their email or their company precisely)
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
<naobsd> not sure gpio# is also swapped(=no actual problem) or not swapped(=wrong)
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
<mmind00> naobsd: actually it's the pinctrl that is swapped
<mmind00> gpio2-31 is the host power, while gpio0-3 is the otg, so the pins themself are correct
<mmind00> so the pinctrl-references are wrong and need to be exchanged
<naobsd> (I'm updating my private dtses...)
<naobsd> btw, why only some node(not all node which uses gpio(s)) define pinctrl?
<naobsd> regulator-name = "otg-vbus"; and regulator-name = "host-pwr"; seens not consistent...
<naobsd> mmind00: I checked RR schematic. gpio0-3 is host
<mmind00> naobsd: that is what I said
<naobsd> I see, sorry :)
<mmind00> the regulator names mimic what the supply is called in the schematics
<mmind00> only adding the "otg" to make it less confusion
<naobsd> ah, I see
amstan has quit [Changing host]
amstan has joined #linux-rockchip
<naobsd> if some pins such as i2cX/pwmX, it should be removed from dts?
<naobsd> I tried to remove uart1, theb I lost serial console at ttyS2 ;)
<naobsd> aaaaaaah
<naobsd> my brain is nearly dead...
<naobsd> I should sleep soon...
<naobsd> let's try...
<temptwo> Back.
<temptwo> Reading backlog, to catch up.
<temptwo> Okay. I grabbed the relevant links, and have them bookmarked. I'm going to have to shut down and move my workstation (office is being reorganized and users moved to new locations). As soon as I'm back up and running, I'll hop in here again, and see if I can't get something moving. Thanks for all the help, and I'll be back asap!
temptwo has quit [Quit: ChatZilla [Firefox 32.0/20140825202822]]
bengal has joined #linux-rockchip
<naobsd> oops, where is &pcfg_pull_default...
<mmind00> naobsd: there is no pull_default on rk3188
<mmind00> rk3066 only has none and (per-pin-)default, while rk3188 can explicitly set the pull direction
<naobsd> well, emmc dts changes for rk30/31 uses it
<mmind00> damn
<naobsd> currently I'm trying master+net-next/master+usb/usb-next+mmind/v3.18-next/dts
viric has quit [Ping timeout: 246 seconds]
AstralixNB has quit [Ping timeout: 250 seconds]
viric has joined #linux-rockchip
<naobsd> oops, forgot to enable dwc2 host...
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
BorgCuba has joined #linux-rockchip
<BorgCuba> hi, I think I just found the source to the on2 libs for the vpu
<BorgCuba> or at least some version of it
<naobsd> aaaaaa
<naobsd> I lost my change :(
<naobsd> zzz...
FreezingCold has quit [Ping timeout: 245 seconds]
<BorgCuba> uploading...
FreezingCold has joined #linux-rockchip
<BorgCuba> here is the code -> dmw96
<BorgCuba> it seems to be all in there!
BorgCuba has quit [Quit: leaving]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
Astralix has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-rockchip
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
Bludot has joined #linux-rockchip
akaizen has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Quit: KVIrc 4.0.4 Insomnia]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
nighty^ has quit [Quit: Disappears in a puff of smoke]
akaizen has joined #linux-rockchip
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-rockchip
akaizen has quit [Ping timeout: 272 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
akaizen has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
akaizen has quit [Remote host closed the connection]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
akaizen has joined #linux-rockchip
viric has quit [Ping timeout: 260 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
temptwo has joined #linux-rockchip
<temptwo> Astralix: Relocation complete. I'm flashing the individual images to one unit, now.
<Astralix> temptwo, good luck. Have to head for bed now...
<temptwo> I'm going to test compiling the entire image from the individual parts as soon as this completes.
<temptwo> Thank you again, for the help. I'll try to ping you tomorrow, and let you know if I was successful or not.
<temptwo> Sleep well, when you get there. :)
<Astralix> Yes, thanks!
<Astralix> I really try to get there...
<temptwo> I always joke that "You can sleep when you're dead."
<temptwo> XD
bengal has quit [Ping timeout: 246 seconds]
<temptwo> Anyway, I'll let you know if I'm successful or not, the next time I see you on here. Thank you, again, for the help earlier!
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-rockchip
akaizen has quit [Ping timeout: 258 seconds]
<temptwo> If anyone else is here and has a moment, how do I confirm whether the Minix X7 mini is using the 3066 or the 3188 loader by default?
<karlp> what do you mean by "loader" ?
<karlp> what linux build are you flashing to the x7 mini? (I've got an x5 mini)
<temptwo> In several of the manuals/guides/how-to docs, they reference RK3066Loader.bin or RK3188Loader.bin as part of the set of files for flashing to a device.
<temptwo> How do I find out what a brand new unit has, by default, before anything has been flashed or changed?
<karlp> which docs are you looking at now?
<temptwo> As for the Linux, it's a custom spin, from someone else. I won't know until I put it on one of the machines.
<temptwo> Pretty much any of the info I've found on the forum. Also, it's included in the RK ROM Dumper and Flasher for Windows.
<temptwo> As well as several other Windows based utilities.
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
<temptwo> Those are the loaders.
<temptwo> I'm trying to see how I can tell what's already on a device. The parameter file is calling the unit a 4.2.2 firmware with a 3066 Machine.
<temptwo> I'm trying to see if I can find the exact version of the 3066, or if that's even accurate. If these are shipping with the 3188, not the 3066, I need to change the loader before I compile the ROM and run this on 80 units. o.o
<karlp> well, what cpu does the x7 minit have?
<temptwo> I don't know. That's why I'm asking how to find out.
<temptwo> You mean the Cortex A9 Quad Core?
<temptwo> It's listed in all of them, in the booklet that came with the units.
<karlp> that's 3188 then
<karlp> 3066 is the dual core
<karlp> (like the x5 mini)
<temptwo> Okay. I wasn't sure, because the parameter.txt I was provided is saying: "Machine: 3066", and I wasn't sure that was right.
<karlp> urh, gpio_dump has the module binary for 3.0.36, but not the app,
<naobsd> why you don't know spec...
<naobsd> ^temptwo
<naobsd> it needs to be clear before anything, not guessing from random thing
<naobsd> before doing anything
<naobsd> and about bootloader version, these should be stock firmware, or any base firmware which includes bootloader bin
<naobsd> s/these/there/
<naobsd> mmm, terrible
<naobsd> headache
<naobsd> I should sleep more...
<naobsd> karlp: you can make module
<temptwo> naobsd: I didn't pick these out or have anything to do with them before today. Even the image is sent to me from outside my company.
<karlp> module installs ok,
<karlp> app refuses to run
<naobsd> temptwo: you cannot ask someone(who send image) about bootloader bin?
<temptwo> So the files call out for things I'm not 100% on. Like the parameter.txt, saying Machine: 3066, when karlp has said the x7 mini quad core is the 3188. I need to find out 100%, so that I know whether to have the origin company fix this, or just change the value in the parameter file.
<temptwo> I'm testing one with the 3188, right now, just to see. I will test another one without specifying the bootloader binary, and see if I get the same result. I have 80 of them to work with.
<naobsd> temptwo: parameter (and everywhere) has a lot of magic number. machine number is one of them
<karlp> hrm, why do I get permission denied trying to run a binary on android? I'm root?
<naobsd> it's not the info to identify your device
<temptwo> Okay. So I don't need to worry about using the bootloader binary when I compile all of these individual parts into the single image to use with the Batch Tool that I was talking to you about, yesterday?
<naobsd> I think bootloader binary is necessary for whole single image
* temptwo nods
<naobsd> know as "update.img" format
<temptwo> I figured it might be.
<temptwo> That's what I'm trying to build.
<naobsd> but actually I never try image w/o bootloader, I don't know
<temptwo> But first I need to know what's actually in the unit.
<naobsd> then, bootloader binary in update.img is flashed to your device, you must use proper version
* temptwo nods
<naobsd> you may get version from running device (serial console or dmesg), and
<temptwo> I just need to find out what's actually in the device, so that I can be sure to use the correct one.
<temptwo> How do I get into the serial console? Is that switching the device into flash mode, and connecting via USB?
<temptwo> Or is there another process?
<naobsd> basically only 1 kind of image exist, you can download from anywhere (such as arctablet) and it will work fine,
<naobsd> well, only 1 for specific version
<naobsd> but
<naobsd> someone who made image should have proper one...
<naobsd> serial console is physical pad/pin/hole on board
<naobsd> well
<karlp> oh, stupid shell wasn't actually making it executable, but was still showing me in ls that it was.
<naobsd> temptwo: it's kitkat?
<temptwo> It's running 4.2.2
<naobsd> temptwo: can you run "dmesg" or "cat /proc/cmdline" on adb shell?
<temptwo> I'm into the default image at another workstation.
<temptwo> I don't have anything connected to the one that's at the other workstation.
<temptwo> I have a Windows computer, I don't have ADB installed on it, and I have another unit that's sitting at the default image "desktop".
<naobsd> what's default image "desktop"...
<temptwo> Android 4.2.2 interface.
<temptwo> It's the default image on the device.
<temptwo> I have plugged the x7 mini HDMI into a monitor, and then plugged in a mouse and power.
Bludot has quit [Quit: Connection closed for inactivity]
<temptwo> What I see on the monitor is the default screen that loads when you first power up the device.
<naobsd> it may be better to write udev rule and script which flashes all individual images automatically ;)
<temptwo> I'm not sure how to describe it otherwise. I don't know if Android uses a different term for desktop. o.o;;
<temptwo> Or I could just find out what I need from the device, and then build the image and put it on a line.
<temptwo> I'll see if I can get some sort of direct interface to the device, and go from there.
<naobsd> sorry for dumb question, why you don't know so much about that device/firmware?
<temptwo> This is my first time even looking at one?
<temptwo> I have other Android devices, but not one of these.
<temptwo> I am new to the RockChip flashing and imaging.
<naobsd> I see
<temptwo> Other devices used different processes.
<naobsd> yes
<temptwo> Thanks for the help, and all, but I guess I'll just see what I can get from poking around in the device and build the update.img with the instructions I found earlier.
<temptwo> I just want to make sure I put the right information into the file, but finding the answers to what the right information is will take some time. That's how learning goes, though. :)
<naobsd> packing image is not difficult, but collecting proper files may be bother a little (especially if no information about device)
<naobsd> is there any app like explorer? can you open /proc/cmdline on android on that device?
<naobsd> or shell app
<naobsd> if your firmware is really 4.2.2 (don't believe number in parameter. you can see version in setting menu on device)
<naobsd> probably it uses bootlader ver 1.x
<naobsd> then, don't use bootloader version 2.x
<naobsd> if you want to use bootloader version 2.x, probably you also need to replace kernel module for NAND
<naobsd> and there are (at least) 2 kind of module which depends kernel internal
* temptwo nods
akaizen has joined #linux-rockchip
<temptwo> Okay. If I have a machine connected to my Windows computer, how do I connect to the serial console? What do I need to have installed, and what do I need to do to the machine? Same as the process for flashing the ROM? Put device in USB mode, pull out power, push paperclip in the pinhole and hold down while plugging power in then take out paperclip and plug in USB? Something different...
<temptwo> ...from that?
<temptwo> Well, I have a machine connected in the USB flash mode, and the flash utility can see it. I have the ADT Bundle unpacking on my desktop. I'm going to leave the office and go home. I'll log in from there, and continue working on this. I should be back in an hour.
<karlp> progress! I have a stock gpio map.
<karlp> tomorrow I return to the ethernet dts work hopefully :)
<karlp> hrm, I should probably poke these scripts to get the _state_ of the stock gpios too, not just the assignments...