ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | IRC log http://irclog.whitequark.org/linux-rockchip | Community GH https://github.com/linux-rockchip | Rockchip GH https://github.com/rockchip-linux | ML https://groups.google.com/group/linux-rockchip
matthias_bgg has quit [Ping timeout: 260 seconds]
lkcl has quit [Ping timeout: 258 seconds]
BenG83 has quit []
kevery has joined #linux-rockchip
lkcl has joined #linux-rockchip
lkcl has quit [Ping timeout: 265 seconds]
vicencb has quit [Quit: Leaving.]
lkcl has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 240 seconds]
kevery1 is now known as kevery
ldevulder__ has joined #linux-rockchip
ldevulder_ has quit [Ping timeout: 265 seconds]
lkcl has quit [Ping timeout: 240 seconds]
return0e_ has joined #linux-rockchip
return0e has quit [Ping timeout: 268 seconds]
lkcl has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 258 seconds]
kevery1 is now known as kevery
_whitelogger has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
kevery has quit [Remote host closed the connection]
kevery has joined #linux-rockchip
<EmilKarlson> so in rockpro64 SPL we already have all of dram available right?
<EmilKarlson> I am having some (many) single bit errors after reading from eMMC and I want to try reading to different parts of dram
<EmilKarlson> I guess there would be a map of the virtual memory space in u-boot somewhere
kevery has quit [Ping timeout: 268 seconds]
<EmilKarlson> well SD
<EmilKarlson> I keep saying eMMC, while it's completely erased now, also I am booting pinebook pro with rockpro64 bootloader
<EmilKarlson> ok complaining on the correct channel fixed the issue
<EmilKarlson> thanks for being here as a deterrent for the code and hardware
<EmilKarlson> I only changed serial baudrate and it works
<EmilKarlson> well also serial adaptor, but I did only use serail for listening, while it was 5V adaptor
<EmilKarlson> while I am ranting, am I the only one who thinks u-boot people are silly for considering configuration to be a hardware feature
<EmilKarlson> like you need to use 1500000 baudrate on rockchip, because silly vendor uses it in their fork
return0e_ has quit [Ping timeout: 240 seconds]
stikonas has joined #linux-rockchip
return0e has joined #linux-rockchip
field^Zzz4 has joined #linux-rockchip
return0e_ has joined #linux-rockchip
return0e has quit [Ping timeout: 268 seconds]
vicencb has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
elektirnis has joined #linux-rockchip
ldevulder_ has joined #linux-rockchip
ldevulder__ has quit [Ping timeout: 268 seconds]
JohnDoe_71Rus has joined #linux-rockchip
vicencb has quit [Quit: Leaving.]
chewitt has joined #linux-rockchip
<anarsoul|c> EmilKarlson: you can set it to 38400 if you want. 115200 won't work
_whitelogger has joined #linux-rockchip
<EmilKarlson> seems to work for me
<EmilKarlson> how does it not work?
Depau has quit [Ping timeout: 268 seconds]
Depau has joined #linux-rockchip
<urjaman> there isnt a clean divisor from 24 Mhz to 115200 IIRC ... tho i dont know what the granularity for the hardware is (1.5M is the max so i'd guess multiples of 16 but not sure)
<urjaman> it could end up with 115384 which isnt even that bad, or something silly like 125k
<EmilKarlson> well it works unusually fine for a 3v3 ttl uart at 115200
<EmilKarlson> no silly typos or garpled text
<EmilKarlson> garbled
<urjaman> different UART chips have different levels of intelligence to deal with mismatched baudrates
<EmilKarlson> well there is always the syncpoint, so you don't need that much intelligence
<EmilKarlson> even my trivial software gpio uart did reset the timings IIRC
<EmilKarlson> you'd have to be off by like more than 10% to fail anything using interrupts for the syncing
<urjaman> more like 1.5% (if you mean by only syncing on start bit)
<urjaman> because it accumulates over all the bits
<EmilKarlson> what do you mean, error would be one measurement too much or too few in measurements in one full cycle, of 8 bits+extras
<urjaman> ah yeah that was the recommended error limit for the majority-of-3 voting AVR UARTs in the fast (8 samples per bit) mode
adjtm has quit [Ping timeout: 268 seconds]
<EmilKarlson> now the issue is mostly that I don't know how to boot arm64 kernels in u-boot
<EmilKarlson> before arm64 this used to be my $dayjob
<urjaman> me neither really (havent booted arm64... have done arm32 at some point, but these days i just let it too use the distro boot method and that's pretty simple in relation to the old days...)
<EmilKarlson> someone has to setup the distro boot method
<EmilKarlson> also most distros are unofficial packages by someone on a russian android forum
<EmilKarlson> distributed as windows executable
Depau has quit [Ping timeout: 268 seconds]
Depau has joined #linux-rockchip
Depau has quit [Ping timeout: 240 seconds]
Depau has joined #linux-rockchip
Depau has quit [Ping timeout: 240 seconds]
adjtm has joined #linux-rockchip
Depau has joined #linux-rockchip
Depau has quit [Ping timeout: 268 seconds]
Depau has joined #linux-rockchip
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
matthias_bgg has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
<tuxd3v> <EmilKarlson> while I am ranting, am I the only one who thinks u-boot people are silly for considering configuration to be a hardware feature
<tuxd3v> <EmilKarlson> like you need to use 1500000 baudrate on rockchip, because silly vendor uses it in their fork
<tuxd3v> No I also think that's idiotic to have a baudrate of 1500000
<fALSO> its non standard
<fALSO> makes everything harder, dont really understand why they chose it
_whitelogger has joined #linux-rockchip
lkcl has quit [Ping timeout: 265 seconds]
stikonas has joined #linux-rockchip