<naobsd>
"This page condenses information found on the net, namely IRC, the G+ talk, the Radxa Rock wiki. Valuable input also came from Galland's blog, androtab.info." this line should be removed
<naobsd>
that wiki is/should be the reliable source. and my idea is not comes from such an random blogs/forums.
<naobsd>
that wiki -> our wiki
<naobsd>
and any link to top page of some forums/blogs is useless. I cannot find any valuable input from those links
<naobsd>
Authoritative sources are source code and continuous trial & error _with real device_. someone's imagination is not the source.
<naobsd>
it may be ok to write something "we guessed", but it should be noted clearly.
<naobsd>
about Binary Bootloader and Linux Kernel Module Dependencies section,
<naobsd>
what happen when bootloader and rknand.ko is mismatched, is error on NAND access
<naobsd>
for example, kernel can boot without NAND
<naobsd>
without NAND -> without rknand.ko
<naobsd>
"Bootloaders are SoC specific, so there's one binary bootloader for every SoC" should be basically true, but not true between rk3066 and rk3188
<naobsd>
sorry
<naobsd>
"Bootloaders are SoC specific, so there's one binary bootloader for every SoC" part is fine
<naobsd>
(corrected) "Version 1 bootloaders have a Linux kernel module rk<SoC>nand_ko.ko.<kVer> corresponding to the SoC and Linux kernel version" should be basically true, but not true between rk3066 and rk3188
<naobsd>
I cannot find "rk31xxnand_ko.ko.(kver)"
<naobsd>
more accurately, some SoCs shares kernel modules
<karlp>
you're editing right now? I'll just let you finish then :)
<karlp>
man, this boot sequences page is certainly getting some traction
<naobsd>
no, not editing. I'm discussion first
<karlp>
good good
<naobsd>
and if I edit it, I'll revert to your version first ;)
<karlp>
"my" version :)
<karlp>
all I did was write down what the results of conversations here were
<karlp>
I've done tiny amounts of verification myself, but mostly just wiki formatting and collating :)
<naobsd>
"Version 2 bootloaders have a Linux kernel module rknand_ko.ko.<kVer>" part is not true for me, I cannot find any "rknand_ko.ko.3.0.8+ and rknand_ko.ko.3.0.36+. These kernel modules are SoC generic."
<karlp>
you're peserverance testing and diagnosing are _greatly_ appreciated
<naobsd>
as far as I know, rknand modules for both loader ver1. and ver2 uses same naming
<naobsd>
next, in "Linux Kernel NAND Module Loading Sequence",
<naobsd>
"The Linux kernel modified by RockChip will first try to load a SoC and Linux kernel version generic rknand_ko.ko module. If this fails it tries next the generic module name with the kernel version appended: rknand_ko.ko.<kVer>." can I see any evidence?
<naobsd>
I can see such a modification in Android's "init" binary
<naobsd>
so insmod line in init*.rc doesn't have trailing .(kver)
<naobsd>
but I don't know such a kernel modification
<naobsd>
...
<naobsd>
my family said "let's go out soon!"
<naobsd>
this is one of the reason I cannot do thing so much :(
<naobsd>
reading wiki carefully and writing comment about it needs some amount of time
<naobsd>
putting random imagination without discussion may be easy...
<naobsd>
let's say some more comments now...
<karlp>
yeah, this current "boot sequences" page has a lot of crazy stuff
<karlp>
I only intended it to cover the maskrom sequences, not second stage bootloaders
<karlp>
they can do _anything_ no way you can ever wiki them
<naobsd>
many "quoted" part uses \(backslash), but it shouldn't. single line must be single line
<naobsd>
or need more comment about it
<hramrach_>
it's still useful to write down what the rk bootloader does
<hramrach_>
because in practice to boot you have to get the kernel loaded by it
<naobsd>
some numbers such as 0x2000 is "sector", not "byte". there are some confusion
<hramrach_>
yes, that Corb guy interpreted the sector number as byte number and created a pretty bogus table
<naobsd>
and only first 4MiB is reserved on SD/eMMC. usgin 40(or 36)MiB for kernel/boot /etc is just my configuration, not system restriction
<naobsd>
hramrach_: what you need is discussion before deleting them. otherwise he will rewrite it again as like as you did
<hramrach_>
I don't know who that person is
<hramrach_>
also getting confused is easy when sector number is called just 'address' throughout wiki
<naobsd>
hramrach_: then please ask it before deleteting. he is field^Mop on here
<naobsd>
sorry, I have to go soon
<naobsd>
no time for discussion for now
<hramrach_>
ok, thanks
<naobsd>
some sector numbers such as 64 are fixed but some others e.g. 92 are not, but it's not error, can be discussed later
<hramrach_>
There is difference between wholesale deleting and actually reading the page and weeding out redundant and bogus stuff
<hramrach_>
yes, presumably they are specified in one of the headers that are copied as magic from existing card because they are not documented anywhere
<naobsd>
"weeding out redundant and bogus stuff" is ok? let's remove whole that wiki now!
<naobsd>
except our todo list
<naobsd>
+ "write wiki really seriously | naobsd" into todo ;)
<naobsd>
"undocumented thing is not written on wiki (yet)" is ok
<naobsd>
"random imagination is written as if the fact" is not ok
<naobsd>
sorry, I really have to go
cnxsoft has joined #linux-rockchip
<karlp>
hramrach_: agreed, rkbootloader is worth documenting, but not getting itno second stage stuff
Tony_ has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
mrcan__ has joined #linux-rockchip
mrcan_ has quit [Ping timeout: 240 seconds]
lioka has quit [Ping timeout: 240 seconds]
lioka has joined #linux-rockchip
Astralix1 has joined #linux-rockchip
Astralix has quit [Ping timeout: 250 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
cosm_ has joined #linux-rockchip
npcomp_ has joined #linux-rockchip
cosm has quit [*.net *.split]
npcomp has quit [*.net *.split]
cyrozap has quit [*.net *.split]
RayFlower has quit [*.net *.split]
dlan has quit [*.net *.split]
hipboi has quit [*.net *.split]
wildea01 has quit [*.net *.split]
else- has quit [*.net *.split]
honx has quit [*.net *.split]
else- has joined #linux-rockchip
hipboi has joined #linux-rockchip
wildea01 has joined #linux-rockchip
honx has joined #linux-rockchip
cyrozap has joined #linux-rockchip
RayFlower has joined #linux-rockchip
dlan has joined #linux-rockchip
RayFlower has quit [*.net *.split]
dlan has quit [*.net *.split]
dlan has joined #linux-rockchip
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
GriefNorth has joined #linux-rockchip
eebrah has quit [Quit: Lost terminal]
eebrah 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
RayFlower has quit [Client Quit]
naobsd has quit [Quit: Page closed]
GriefNorth has quit [Read error: Connection reset by peer]
gb_master has joined #linux-rockchip
hipboi has quit [Ping timeout: 255 seconds]
Tony_ has quit [Quit: Leaving]
hipboi has joined #linux-rockchip
VargaD_ has joined #linux-rockchip
VargaD has quit [Ping timeout: 264 seconds]
VargaD_ is now known as VargaD
cnxsoft has quit [Ping timeout: 272 seconds]
hipboi has quit [Ping timeout: 256 seconds]
<rperier>
mhhh
<rperier>
so
<rperier>
my radxa rock pro works fine with android 4.4 kitkat stock, I have a working mouse, a graphic stack
<rperier>
hdmi works
<rperier>
the green led is blinking
<rperier>
BUT
<rperier>
I no longer have usb debug output now
<rperier>
:/
<hramrach_>
the blinking led part is rather annoying
<rperier>
yesterday it was buggy with stranges characters.... and now nothing
<hramrach_>
you mean serial debug?
<rperier>
I use the same usb serial than on RR (first revison)...
<rperier>
hramrach_: the uart uses to get system and kernel logs
<rperier>
used*
<hramrach_>
hmm, maybe something really is broken
<hramrach_>
does the USB serial adapter still work with the other board?
<hramrach_>
if so you can try disconnecting/reconnecting stuff. Sometimes the cables are just loose
<hramrach_>
also configuring another serial port on one of the extension headers might help
<hramrach_>
but you will need to reconfigure kernel and/or dt to use the other port then
* hramrach_
wonders here is pinout for the headers
<hramrach_>
but radxa claims the board is oshw so it should be *somewhere*
hipboi has joined #linux-rockchip
field^Mop has joined #linux-rockchip
<rperier>
I use an usb serial "Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light" , which works just fine with the radxa rock first edition
<BorgCuba>
hramrach_, are you working on the(?) linux-rockchip kernel?
<hramrach_>
no. did not really get anything but prebuilt image booting
<BorgCuba>
I was talking to naobsd some month ago and I think he mentioned that there are affords to have something like "linux-sunxi" for rockchip devices
<hramrach_>
it's more difficult with rockchip
<hramrach_>
for various reasons
<BorgCuba>
yes, i saw some reasons already
<hramrach_>
the technical reason being that the configuration for rockchip kernel is written to a .c file at compile time so reusing prebuilt vendor kernel on other devices is problematic
<hramrach_>
it would be possible with mainline+dtb but support for that is progressing slowly
<BorgCuba>
board_rk30-sdk.c?
<hramrach_>
yes
<hramrach_>
or some file like that. when you make new device you edit that to match hardware configuration an rebuild kernel ...
<BorgCuba>
a while back I checked out this newer kernel (linux-next)
<Astralix1>
I am working with normal USB dongle and have one preview rock that doesn't work most times with debug. The other preview and the rock pro work fine
<Astralix1>
hramrach_ that git should be fine
<hramrach_>
ok, thanks
<Astralix1>
rperier, the levels on the preview rock are exactly 3.00V with my board.My USB dongle does work down to 1.2V and so I do not see any problems.
<BorgCuba>
Astralix1, thats just something I found on some ftp server
<rperier>
Astralix1: my USB TTL is compatible with 5V and 3.3V
<Astralix1>
The board not giving any response has probably got an ESD shot as on the scope you can see communication, but while high level is at 3.1V the low level is at 2.5V what is mucht too high to be accepted as 0 level.
<hramrach_>
yes, using that mkimage creates working kernel image which panics nicely
<BorgCuba>
since I thought this might be interesting to other people as well (and I knew that a similar codec is used in the rk3xxx devices) I uploaded it to github
<BorgCuba>
I also have a rk3188 device where the usb-tx->rk-rx link is broken
<Astralix1>
BorgCuba, did you get this to work in any configuration?
<BorgCuba>
the vpu codecs?
<Astralix1>
yes
<BorgCuba>
no, I dont have a working linux environment for any of my rockchip devices yet
<Astralix1>
ah, ok
<c0d3z3r0>
rperier, Astralix1: I have the same problems with my cheap china usb ttl. i can only read but not send data to the radxa. but when I connect the radxa to my raspberry pi's uart everything works just fine
<Astralix1>
So why don't you use the raspi ?
<Astralix1>
These china dongles are well know to be often bad copies of good chips.
<hramrach_>
I wonder where I lost the ttyFIQ?
<hramrach_>
and why it panics failing to find mmcblk0p1, the only block device I have? :/
<Astralix1>
I am using these little boards private and in the company and I use dozends of them
<hramrach_>
well, 3.18 patched with random unrelated stuff because I just had it on my disk
<BorgCuba>
Astralix1, I am using this old sparkfun ft232 breakout board for years and I never had problems
<BorgCuba>
hramrach_, I didnt know that there is a 3.18 with rockchip support?
<hramrach_>
yes, people keep praising ft chips
<Astralix1>
BorgCuba, I am not aware of any problem with this chips. There where some in the past, but that is years ago. But I use these boards for years now and regardless of ARMv4, Cortex M, RK, Mediatek or even an old AVR, it simply works
<hramrach_>
BorgCuba: there is but does not work for me?
<BorgCuba>
but I think it didnt work out of the box for me either
<hramrach_>
I use pl2303 because it is cheapest and works ok so far
<rperier>
Astralix1: so for you... it's an electrical issue, the voltage or the signal is too high or not correct for the chipset integrated into the usb ttl ?
<BorgCuba>
Astralix1, I think my problem with the broken pc->rk link must be related to the rk side since it was working for some weeks without problems
<hramrach_>
BorgCuba: yes, read that
<hramrach_>
it just says to use upstream
<rperier>
Astralix1: I have a CP2102 and it does not work
<hramrach_>
and my kernel is 3.18 with patches that only apply to other platform
<Astralix1>
rperier: yes. The level of the TX line is too high. probably the down side FET in the output of the RK SOC got shot.
<hramrach_>
hmm, technically the dma patches may affect rk
<BorgCuba>
okay guys, I have to leave now. cu
<rperier>
anyone did test usb ttl for radxa ? (the green one that you can buy on the radxa store)
<Astralix1>
I have one too but it is the RK / radxa that doesn't work, not the CP2102. If I connect it to a different radxa, it works fine
BorgCuba has quit [Quit: leaving]
<rperier>
it includes a pl2303 If I remember correctly
<hramrach_>
I guess I will try another kernel
<rperier>
Astralix1: typically, my CP2102 works just fine with my radxa rock first edition (2013) and not with my radxa rock pro
faddat has joined #linux-rockchip
<Astralix1>
rperier, if I look at my scope, it is the TX line of the rock, which is dead... I checked it without connecting anything to the pin
<Astralix1>
So in this measurement there was no USB chip involved
nighty-_ has joined #linux-rockchip
<rperier>
Astralix1: I got characters yesterday evening when I tested USB TTL (readable and unreadable characters)
<hramrach_>
if tx does not go low maybe there should be a pulldown and isn't?
<rperier>
and today, no output
<hramrach_>
is it configurable somewhere on the software side?
<Astralix1>
hmm...
<Astralix1>
rperier, try to see the output from the Loader
<rperier>
no you don't understand, I get nothing
<rperier>
even from the loader
faddat has quit [Ping timeout: 240 seconds]
<Astralix1>
Yes I understand, I just try to check the details
<rperier>
the board works fine, I booted android 4.4 this morning with a working mouse, a working hdmi and a working ethernet... it's just the usb ttl...
<rperier>
very strange
<Astralix1>
The same with my defective board
<Astralix1>
And it is somewhat more strange... At work the board didn't show any serial output, at home it did!
<Astralix1>
Now it doesn't show anything again, even at home
<hramrach_>
do you have the board always connected to something?
<hramrach_>
If moving it helped maybe disconnecting everything for a few minutes would too
<rperier>
if I cannot get a working usb ttl... this board is just useless, it is for developing...
<rperier>
even if this board was free... I am not lucky :(
<rperier>
Astralix1: did you find a way to get logs on your defective board ?
<Astralix1>
Didn't try, but you probably can try to use one of the other UARTs of the chip as your debug output.
<Astralix1>
Some of them should be available at the connectors at the side
<Astralix1>
J8 pin 13 (UART0_RX) and pin 14 (UART0_TX)
<Astralix1>
But I wonder how you might have killed your debug UART as the rock pro has some extra safety parts around it.
<Astralix1>
In worst case you killed Q10 a simple FET that can be replaced
<Astralix1>
I do not have any gamma-ray eyes, so hard to tell if it is a true CP2102 or a faked one or if it is broken...
<Astralix1>
You could do some measurements, but only if you have a scope and know how to use it
<rperier>
I can do it with a friend at work tomorrow
<Astralix1>
You get the schematics at radxa homepage, download the right ones. Check page 6 on the schematics. There is the Debug UART pin header and its protection circuits.
<Astralix1>
You should check if Q10 works as expected.
JohnDoe_71Rus has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
JohnDoe_71Rus has quit [Changing host]
bengal has joined #linux-rockchip
<rperier>
on the forum someones that there is an integrated TTL bridge on radxa.... wtf ?
nighty-_ has quit [Quit: Disappears in a puff of smoke]
GriefNorth has quit [Ping timeout: 240 seconds]
<Astralix1>
rperier: Yes it is. There is some circuitry that protects the low voltage GPIOs from normal 3V3 and 5V USARTs.
<hramrach_>
I can use my 5V uart which is useless otherwise \o/
<Astralix1>
I would like to discuss that point with my colleagues on monday
<Astralix1>
I would not use a 5V UART adapter
<Astralix1>
afaik the protection diodes are 1.7V and 5V will put 3.2V on a 1.8V line...
<Astralix1>
3.3V
<Astralix1>
But it is written on radxa FAQ that you should only use 3V3 UART adapters. So no 5V!
<rperier>
I don't understand how it can work with old radxa rock and not with this one
gb_master has joined #linux-rockchip
RayFlower has joined #linux-rockchip
<Astralix1>
rperier, did you try a different adapter and it works?
<hramrach_>
hmm, ok
<hramrach_>
the rk DT is just bogus so no wonder mmc does not work
<hramrach_>
actually it's the mk908 one which is bogus. rr is not obviously broken
gb_master has quit [Quit: Leaving]
<hramrach_>
it fails differently now
<hramrach_>
dwmmc_rockchip 10214000.dwmmc: DW MMC controller at irq 55, 32 bit host data width, 128 deep fifo
<hramrach_>
Unable to handle kernel NULL pointer dereference at virtual address 00000000
* hramrach_
&
field^Mop has joined #linux-rockchip
cosm has joined #linux-rockchip
rz2k has quit [Read error: Connection reset by peer]
<field^Mop>
hramrach_: you gotta be kiddin me!?
<field^Mop>
i put some f**** lot of time into the rewrite of this article.
<field^Mop>
damn
<field^Mop>
naobsd: what's the fuzz about this?
<field^Mop>
there has been clearly written that it's still work in progress and stuff got to be sorted out.
cosm has quit [Remote host closed the connection]
<field^Mop>
now, all the mods and clarifications are gone. there have been errors, yes, but that's what I asked in this channel to be told of so I could fix it
<field^Mop>
it's been clearly a progress since the original page. from the start it was all a mess of information and disinformation. paste and let rot.
<field^Mop>
surely no one except insiders is able to get that stuff as it was.
<field^Mop>
are*
<field^Mop>
I'm somewhat pissed off, I can tell..
<field^Mop>
guys.. this sucks
<hramrach_>
field^Mop: which of the part that is gone was clarification?
<hramrach_>
you have history in the wiki
<field^Mop>
boot sequences _is_ covering from 0 to root: prompt, generally..
<hramrach_>
is it not now?
<field^Mop>
hramrach_: i.e. that part that still needed attention.
<hramrach_>
it is missing from start of linux the prompt but that's not particularly rk specific and was not there in the first place
<hramrach_>
*start of linux kernel to the prompt
<field^Mop>
it was also the part naobsd and karlp eagerly wanted added to exactly this page. the stuff about the header signature etc.
<field^Mop>
hramrach_: sure. what do i know.
<hramrach_>
there was nothing about header signature that was removed
<field^Mop>
it seems the article got cut back to one tenth of the content I started to build up.
<field^Mop>
?
<hramrach_>
you did not build up content. you built up verbose prose. the point of the article is to record information not to write a novel
<field^Mop>
table is gone..
<hramrach_>
no table is gone. it is fixed . bogus data removed
<field^Mop>
hramrach_: ok, if you're the authority that dictates how volunteers try to contribute, then be alone.
<hramrach_>
but there is history. I might have missed something
<field^Mop>
hramrach_: the table is telling nothing to someone new to the topic and trying to gain knowledge.
<field^Mop>
pittyful
<hramrach_>
so if you think much was removed then please open two browser windows with the historic version and the current version and say what is missing
<hramrach_>
how would you tell more?
<hramrach_>
it has all the info there is
<field^Mop>
hramrach_: instead of pasting illegible broken english from irc that have to be decrypted.. i prefer clearly_ prose
<field^Mop>
hramrach_: missing is all that you just reverted..
<field^Mop>
this is ridiculous
<field^Mop>
hramrach_: if you want to preserve your status as insider and prevent others from learning and contributing, go on then.
<field^Mop>
else I think your "prose" is something the rest of the world is calling sensible documentation.
<field^Mop>
irc log pasting is definitely not.
<hramrach_>
field^Mop: if you feel much information is missing then tell me what information, please
<field^Mop>
hramrach_: i told you again and again. it's virtually everything, that is missing.
<field^Mop>
btw, wtf is 0x200 (logical 0) ?
<hramrach_>
did you read the neighbor cell and the 2-line paragraph just below the table?
<field^Mop>
why is sector 0x2000 at the end of the table, it is actually located before 64. or the table is misleading and cannot be interpreted except by insiders. and that is what I try to fix. this elitarism-prose of yours.
<hramrach_>
no, it is not
<field^Mop>
yes, a lot of times. it is telling me nothing at all
<field^Mop>
instead of just reverting the effort of someone honestly interested and contributing you should maybe try to imagine and _ask_, then discuss and finally improve.
<field^Mop>
the text below the table is nonsense.
naobsd has joined #linux-rockchip
<field^Mop>
it is not to understand for non-insiders. it is not even understandable english.
<hramrach_>
field^Mop: I reverted it because it was bogus and I did not know who wrote it
<field^Mop>
well, tell me, is it non-bogus now? don't answer.
<field^Mop>
it is _not_
<field^Mop>
bullshit this is
<hramrach_>
it is non-bogus in the sense that it does not place sector 0x2000 before sector 64
<hramrach_>
0x2000 is clearly more than 64
<akaizen>
naobsd: what are your thoughts on the firefly?
<field^Mop>
depends on how it is understood. and thats the basic flaw of the actual version.
<hramrach_>
but yes, it is in the original chenglish in which some old version of the articla was written so it is not exactly pleasing to read
<field^Mop>
and that is what I try to improve. that _anyone_ can understand what the doc says.
<field^Mop>
hramrach_: that is an understatement.
<naobsd>
hramrach_: I'll revert your change by the reason you told now
<hramrach_>
which change and which reason?
<hramrach_>
if you revert to karlp version of the article it does not improve the phrasing
<field^Mop>
I would like to revert the page to the last state I left it, then I'd like to ask you and anyone else to help me understand how to understand and I will correct every single bit.
<naobsd>
field^Mop: discuss later about improvement of your changes
<field^Mop>
it is a process, writing such an article. it is not done in one evening or such.
<field^Mop>
well, I'm cooling down a bit.
* field^Mop
takes a deep breath
<hramrach_>
field^Mop: ok, so what do you not understand about the section with the table?
<field^Mop>
one difficulty is the time offset between us
<field^Mop>
live discussion is difficult this way
<naobsd>
field^Mop: I said later, I'm on train to office now :)
<hramrach_>
I know what it says by now so I do, of course, understand it
<field^Mop>
naobsd: :)
<field^Mop>
I'm about to leave..
<field^Mop>
hramrach_: yes
<field^Mop>
so, I'd like to revert to my last edit. then we could start with the section with the table. once this is fixed, we can walk through the complete doc.
<hramrach_>
please don't. I would like the article to be as short as possible, Adding length does not improve understanding
<field^Mop>
as stated in the section itself it is just rephrasing and awaiting clean up.
<field^Mop>
Astralix1: yes. and redundancy. because it is not yet reworked.
<Astralix1>
A bit too late to start reworking it for me, but yes
<hramrach_>
ok, take the current version as rework
<naobsd>
cleanup is needed, but discuss first
<field^Mop>
Astralix1: *g it is too late, yes, I'm about to leave..
<field^Mop>
naobsd: yes, ok
<field^Mop>
discuss 1st, cleanup after having understood. good plan.
<hramrach_>
I put some effort into ordering the sections logically. Which also revealed that most sections were repeated in your version
<Astralix1>
Is there an option to write some new versions of it and discuss them before putting them online?
<Astralix1>
Yes, I see
<Astralix1>
hramrach_ but there is still need for cleaning things up.
<field^Mop>
hramrach_: hm. if I understand you correctly, you unified sections or section naming.
<field^Mop>
my intention was to structure the text as a whole.
<naobsd>
only hramrach_ agreed that reverting bogus edit first, so I'll do it his bogus edit
<Astralix1>
??
<field^Mop>
?
bengal has quit [Ping timeout: 258 seconds]
<Astralix1>
:)
<field^Mop>
this table is a center point in the document. it is essential to get this right and write it in a way newcomers are able to see what it has to say.
<hramrach_>
and what is missing form the table that newcomers are not going to see?
<naobsd>
field^Mop Astralix1 I commented some about your changes, please check log
<field^Mop>
I would suggest to diff the changes hramrach_ did on top of my last edit. then maybe discuss the changes and merge them on top of my last edit.
<field^Mop>
naobsd: hm, I still have to read todays backlog. I only started and noted the discussion about the page and I left reading the backlog at that point..
<hramrach_>
I ordered the sections so that you get from power on to loading Linux, from top to bottom
<hramrach_>
previously they were ordered at random
<hramrach_>
naobsd: is there some way to enter rkusb on purpose when you have a valid image flashed?
<Astralix1>
For me it looks fine and I disagree a bit about the fact that new user should understand the bootloader
<field^Mop>
naobsd: insteresting, your notes about the kernel module part. can't remember who it was, but it was a couple of days ago when someone here told me these details about the mod deps and stuff. it was more accurate than what was in that section before. but it seems, there's still more to it.
<field^Mop>
hramrach_: what exactly seemed random? I felt it more structured that way.
<field^Mop>
Astralix1: you believe new users should not be able to understand the bootloader?
<hramrach_>
it was obviously not structured if the same thing was described in several places
naobsd has quit [Ping timeout: 246 seconds]
<Astralix1>
fiel^Mdop, I guess this is an extra section to explay how a loader works and what take care of. It must not fit into a single section.
<Astralix1>
*explain
<hramrach_>
I think new users should be able to understand bootloader if they want to. Just like there is gazillion docs for PC boot sequence you can refer to and which you can take as reference if you want to create, say, a bootable floppy we should have same for rk
<field^Mop>
naobsd: those backslashes are for the representation in the wiki. w/o there is one hugely long line that is leaking the page layout.
<Astralix1>
It is hard to decide what is normal and what is expert knowhow
<Astralix1>
And in this the boot sequence is drawn pretty fine.
<field^Mop>
Astralix1: ok, we could split that section up into others. r8. probably that is what would have happened anyway if that section already had undergone rewriting.
<Astralix1>
Ok, let me explain it different
<Astralix1>
If a user is reading the document, he should be able to find a point where he can find a knowledge access to it
<Astralix1>
From that point down he should be able to read and understand, even he did not understand the things before
<Astralix1>
Yes
<Astralix1>
And that is what I meant
<Astralix1>
In 1032 you write one line about the loader, referring to a dead link
<field^Mop>
naobsd: the note at the top about the source of information is imo important. it is important to know where to look for the original input when in doubt, i.e.
<Astralix1>
Before the Contents there is a somewhat detailed explanation, taking care of details that should be explained later
<field^Mop>
Astralix1: well, I am familiar with this but the text is often not clear to me
<Astralix1>
It needs some tiny reworks, but it is explaining the details for those, who know.
<field^Mop>
hm, I fell like this way I'm getting nowhere..
<Astralix1>
But if you don't know, you can continue to the next section and read about things you might know
<field^Mop>
maybe I should write my private doc, clearify the missing bits and leave the wiki the way it is.
<Astralix1>
no
<Astralix1>
I didn't read the logs
<field^Mop>
Astralix1: I don't understand..
<field^Mop>
me neither today.
<Astralix1>
may be someone already told you exactly the opposite
<Astralix1>
Ok: easy:
<Astralix1>
I am a non-tech user
<Astralix1>
I read the page and see SRAM, DRAM... wft???
<hramrach_>
then you see that the page is technical
<Astralix1>
Someone in the forum says I need to enter MaskROm... Cool there is a headline
<Astralix1>
It tells me how to enter MaskROM
<Astralix1>
I read, follow and I found what I looked for
<Astralix1>
Now I am the tech guy
<Astralix1>
I see the page with lots of details and I read everything from the beginning, but skip the part how to enter the MaskROM, as I already know this
<field^Mop>
rperier: your symptom description about the uart bad chars sounds a bit like what I experienced here when using a pl203 usb-serial adapter. using a ftdi or a raspi fixed that problem for me.
naobsd has joined #linux-rockchip
<field^Mop>
Astralix1: ok. so, what now?
<naobsd>
train train
<Astralix1>
Keep the more detailed things, and take care to pick up the different clases of users at some point.
<hramrach_>
naobsd: btw, do you have a device with emmc? or know somebody who has?
<naobsd>
field^Mop: lets write detail as much as possible. for beginner, another easy howto is enough
<Astralix1>
One is correct 3V levels, the other one is the locked out one.
<Astralix1>
naobsd I agree
<Astralix1>
Beginners will read the captions and decide which are interesting for them. So we should try to find meaningful captions.
<Astralix1>
hramrach_ what device should have eMMC? RK31 or 32?
c0d3z3r0 has quit [Ping timeout: 264 seconds]
c0d3z3r0 has joined #linux-rockchip
naobsd has quit [Ping timeout: 246 seconds]
naobsd has joined #linux-rockchip
<hramrach_>
I would expect you can connect it to any. It acts as normal mmc, right?
<hramrach_>
can rk boot from mmc1?
<hramrach_>
naobsd: also do you have some idea what is the structure of the magic header?
<hramrach_>
naobsd: also what are the flags for rkflashtool b ?
<hramrach_>
I do not see them documented neither in the help text nor readme nor interpreted in the code. afaict they are just passed on
<Astralix1>
I do not know what these flags do...
<hramrach_>
iirc you explained them sometime here but I cannot find it in the logs
<Astralix1>
You should be able to boot from SD/MMC on both sockets and you should be aware that RK30xx does not support boot from eMMC
<Astralix1>
ah
<field^Mop>
so, I reaaaally need to get afk..
<Astralix1>
have some nice dreams!
<field^Mop>
hramrach_: yes, rkflashtool has quite some undocumented parms..
<field^Mop>
*g
<Astralix1>
I am leaving in a few minutes too
<naobsd>
field^Mop: later
<hramrach_>
see you :)
<field^Mop>
byby, thx
<naobsd>
I'll away very soon too
<Astralix1>
hramrach_: rkflashtool p is for reading parameters
<hramrach_>
b
<hramrach_>
not p
<hramrach_>
b
<Astralix1>
b is for boot
<Astralix1>
in my version it just reboots
<hramrach_>
but what are the flags?
<hramrach_>
it takes flag and passes it over with the command
<Astralix1>
I guess naobsd has an upgraded version that supports booting into some special condition, but my version doesn't support that
<field^Mop>
next steps I'd take would be: isolate hramrach_ changes he put on top of my last edit and iff applicable apply them on top of my last one, then continue editing, discussing. preferably first fixing the table, then the boot sequence section (the long, redundant one).
naobsd has quit [Quit: Page closed]
<Astralix1>
technically you can write your kernel to DRAM and pass your command line to it
<Astralix1>
All via rkflashtool, but I didn't use it that much.
<Astralix1>
field^Mop, right. That would be great. But take your time