ganbold has quit [Remote host closed the connection]
_whitelogger_ has joined #linux-sunxi
_whitelogger has quit [Remote host closed the connection]
jemk has quit [Ping timeout: 252 seconds]
jemk has joined #linux-sunxi
TheSeven has quit [Ping timeout: 264 seconds]
[7] has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 245 seconds]
quadjfet has quit [Quit: Leaving]
quadjfet has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
nexgen has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
AneoX has joined #linux-sunxi
DonkeyHotei has quit [Read error: Connection reset by peer]
DonkeyHotei has joined #linux-sunxi
sunshavi has quit [Ping timeout: 258 seconds]
[7] has quit [Ping timeout: 264 seconds]
tllim has joined #linux-sunxi
TheSeven has joined #linux-sunxi
florian has joined #linux-sunxi
diego_r has joined #linux-sunxi
return0e_ has quit [Ping timeout: 248 seconds]
diego_r has quit [Ping timeout: 258 seconds]
msevo has joined #linux-sunxi
diego_r has joined #linux-sunxi
jbrown has quit [Ping timeout: 264 seconds]
chewitt has joined #linux-sunxi
hlauer has joined #linux-sunxi
gsz has joined #linux-sunxi
tdebrouw has joined #linux-sunxi
tllim has quit [Read error: Connection reset by peer]
florian has quit [Ping timeout: 258 seconds]
jstefanop has joined #linux-sunxi
jstefanop has quit [Remote host closed the connection]
user4 has joined #linux-sunxi
xcko has joined #linux-sunxi
jstefanop has joined #linux-sunxi
user3 has quit [Ping timeout: 244 seconds]
jstefanop has quit [Ping timeout: 246 seconds]
user4 has quit [Quit: WeeChat 2.3]
antoine89 has joined #linux-sunxi
NeuroScr has quit [Quit: NeuroScr]
quadjfet has quit [Quit: Leaving]
nexgen has quit [Quit: Leaving]
jbrown has joined #linux-sunxi
nexgen has joined #linux-sunxi
florian has joined #linux-sunxi
SopaXorzTaker has joined #linux-sunxi
random_yanek has quit [Read error: Connection reset by peer]
swiftgeek has quit [Ping timeout: 268 seconds]
random_yanek has joined #linux-sunxi
swiftgeek has joined #linux-sunxi
<fALSO>
bom dia
Da_Coynul has joined #linux-sunxi
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
megi has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
Da_Coynul has quit [Client Quit]
Da_Coynul has joined #linux-sunxi
tuxillo has quit [Remote host closed the connection]
return0e has joined #linux-sunxi
jernej has quit [Read error: Connection reset by peer]
jernej has joined #linux-sunxi
tuxillo has joined #linux-sunxi
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
arete74 has quit [Ping timeout: 245 seconds]
Mangy_Dog has joined #linux-sunxi
gsz has quit [Quit: Konversation terminated!]
jbrown has quit [Ping timeout: 252 seconds]
jbrown has joined #linux-sunxi
chewitt has quit [Read error: Connection reset by peer]
florian_kc has joined #linux-sunxi
gaston_ has joined #linux-sunxi
nexgen has quit [Quit: Leaving]
dddddd has joined #linux-sunxi
chewitt has joined #linux-sunxi
megi has quit [Ping timeout: 248 seconds]
lurchi__ has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 245 seconds]
msevo has quit [Quit: Leaving]
afaerber has quit [Quit: Leaving]
nexgen has joined #linux-sunxi
jelly has quit [Read error: Connection reset by peer]
jelly-home has joined #linux-sunxi
tllim has joined #linux-sunxi
ed_peguillan has quit [Quit: Leaving]
megi has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
cnxsoft has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
ed_peguillan has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
hlauer has quit [Ping timeout: 268 seconds]
tuxillo has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
tuxillo has joined #linux-sunxi
Putti has joined #linux-sunxi
jstefanop has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-sunxi
jstefanop has quit [Ping timeout: 252 seconds]
jbrown has quit [Ping timeout: 252 seconds]
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 248 seconds]
jstefanop has joined #linux-sunxi
jstefanop has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-sunxi
reinforce has joined #linux-sunxi
jbrown has joined #linux-sunxi
diego_r has quit [Ping timeout: 258 seconds]
florian_kc has quit [Ping timeout: 244 seconds]
<antoine89>
hi. I have a question about u-boot. I own a A20-Lime2 without internal memory and it makes use of an microSD card for the OS. I wonder if the uboot is written in the SPI flash. I tried to reinstall uboot from FEL, and I installed a different OS on a different card. My eeprom is empty, but when I booted, I get the same MAC address, so I assume this is because the uboot is written in the SPI. Can anyone
<antoine89>
confirm this?
florian has quit [Quit: Leaving]
<KotCzarny>
clear the spi and you will see
<mru>
the u-boot messages should indicate where it's loading from
jstefanop has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
jstefanop has quit [Ping timeout: 252 seconds]
<antoine89>
thanks. it seems the uboot comes together with the OS on the microSD card. I can also see that uboot gets that MAC address from a ROM: "Warning: usb_ether using MAC address from ROM" Which ROM is that? I want to remove that MAC address from ROM. Is this possible?
<mru>
not if it's a true ROM
<antoine89>
I would take the risk of damaging the board by phisically removing the chip
marvs has joined #linux-sunxi
<mru>
which chip?
<antoine89>
Olimex A20Lime2 board. I dont know which chip. I'll spend some time looking for schematics
<mru>
what's wrong with the mac address anyway?
<antoine89>
I want anon router
<antoine89>
not only that, but like if i use JS, I dont want google to be able to ID my board
<mru>
the mac address doesn't leave your local network
<antoine89>
I think you're wrong. Many websites idetify the device you use and all of its properties
<mru>
impossible
<mru>
they can identify things in many other ways
<mru>
not from the mac address though
<mru>
becuase they can't see it
<antoine89>
Actually maybe you're right about that, because it wouldnt matter. Because I think they can see all teh ID's of the specific part of your board
<antoine89>
So when for example you use facebook, they corelate multiple profiles to the same device
<mru>
a website knows only what the browser tells it
<antoine89>
No buddy
<mru>
and the ip address of course
<mru>
how do you suppose a server can find anything out without the browser telling it?
<mru>
ok, they might do nmap-style analysis of tcp streams and such
<mru>
not much you can do to stop that
<antoine89>
if you want I can take this privately, but you can do your own research. I am not here to debate. I am here to ask about my mac address
igraltist has quit [Remote host closed the connection]
<mru>
we're talking about facts, so there's nothing to debate
<mru>
anyhow, you can override the default mac address in many places
<mru>
but don't think it will help you stay anonymous
igraltist has joined #linux-sunxi
<antoine89>
I tend to agree about your last statement
<mru>
there are thousands of parameters readily available in http requests and via js that can be used for fingerprinting
<antoine89>
I already told you that a JS website can see all the ID's of the chips you have in your PC
<mru>
I doubt that
<antoine89>
its a fact!!!
<mru>
so show me
<mru>
where's the api reference?
<antoine89>
ok hold on
<KotCzarny>
if you have a way for getting mac address of pc with a js, i want it too
<KotCzarny>
:)
<antoine89>
Not only the mac address but the serials of all your chips
<mru>
lol
<KotCzarny>
please, show me the code
<KotCzarny>
so i can test
<KotCzarny>
i was looking for a way for years
<antoine89>
i dont know you guys maybe I was wrong, and you win
<antoine89>
but let me worry about why I want to do whatever I want, it is more of theoretical exercise
<mru>
on most systems, the browser is able to find the mac address, so it _could_ expose it with to JS
<mru>
but I've never heard of that being done
<KotCzarny>
mru, code or gtfo :P
<mru>
if you can run "ip addr" in a terminal, the browser can do the equivalent
<mru>
that doesn't mean it actually does this
<KotCzarny>
browser dont let you run code in a terminal
<KotCzarny>
if they do, they are backdoored
quadjfet has joined #linux-sunxi
<antoine89>
did you ever try to run multiple facebook profiles on the same device?
<mru>
what I mean is that the firefox (or whatever) process typically has permission to find out the mac address of any network interface
<mru>
so it _could_ theoretically provide a JS api to get it
<KotCzarny>
mru, find out, maybe, but doesnt expose it to js
<mru>
exactly
<mru>
I obviously can't prove that there isn't a browser that has such an api
<KotCzarny>
it needs some ExploitX or binary extension
<mru>
or that some unrelated api doesn't accidentally leak that information
<antoine89>
Could they use cookies for that?
<mru>
facebook uses cookies for persistent login, yes
<antoine89>
could the cookies fingerprint your device?
<KotCzarny>
read about 'super cookies'
<mru>
cookies are set by the website
<KotCzarny>
regular cookies are easy to nuke
<mru>
even "super cookies" are set by someone
<KotCzarny>
browser offer persistent storage for quite some time
<KotCzarny>
additionally to normal cookies
<mru>
I know
<KotCzarny>
*browsers
<mru>
and it's easy to clear
<KotCzarny>
mru, if you know about it, yes
<KotCzarny>
:)
<mru>
persistent storage isn't really that special
jelly-home is now known as jelly
<KotCzarny>
yeah, but most people dont know about it
<mru>
it's like cookies, but for larger amounts of data
<mru>
and doesn't get sent with each http request
gamelaster has joined #linux-sunxi
<KotCzarny>
but they are (ab)used to store unique id
<mru>
I don't have a problem with websites storing a login token
<antoine89>
i cant remember the name of it but I thougt there was a tracking company that once you allowed JS from a website that uses them for anaylitics, they know all your device history across from all their customers
<antoine89>
I wasnt plannign to use it for that
<antoine89>
I was thinking to get myself a nice router, and have as little info as possible on it in case I get hacket
<KotCzarny>
i usually run with noscript enabled by default
<KotCzarny>
safer these days
ninolein has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
<montjoie>
noscript os not enough, umatrix to the rescue!
<antoine89>
it would of been nice to just change the sd card and get a whole new OS
<antoine89>
no mac address, no chip ids, no nothing to id you
<mru>
you're barking up the wrong tree
<KotCzarny>
you can generate random mac address in rc.local
<KotCzarny>
if that quells your phobias
<mru>
nothing you do on a router will prevent tracking of browsers running on devices behind it
<mru>
if you want to avoid all possibility of being tracked, you should probably stick to gopher
<kilobyte>
gopher over tor, of course
<antoine89>
omg I'm that not paranoid.
<kilobyte>
well, IP is probably the easiest way to track you
<antoine89>
anyway, I whoutght to do it as an exercise, to see how far I get a board to be
<martinayotte>
don't forget that ISP modem has also MAC ... :-P
<antoine89>
if you run vpn on your router, it doesnt matter though
<antoine89>
yeah, to basically blank out my board, no ids/macs...
<antoine89>
maybe I could write in the SPI flash custom ID's?
<antoine89>
anyone know somehting about that?
<antoine89>
like macchanger script
chewitt has quit [Quit: Adios!]
<antoine89>
I'll still try to remove the mac from my internal rom, will tell you how it goes
<antoine89>
what a waste of time to have this conversation
antoine89 has left #linux-sunxi ["WeeChat 2.3"]
<KotCzarny>
o.O
<ElBarto>
so for the case of a64 tcon0 and anx6345, is the tcon supposed to be a drm_encoder and the anx6345 a drm_bridge + drm_connector ?
<ElBarto>
anarsoul: jernej: ^^^ (if you could help me on that it would be great :P)
craigo has quit [Ping timeout: 258 seconds]
<libv>
anarsoul: ^
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
<libv>
ah, missed anarsoul being mentioned
<ElBarto>
:) thanks
<libv>
ElBarto: the anx is the encoder, traditionally
<ElBarto>
there is a few good talks about drm internal but it's really not enough to answer all my questions
<ElBarto>
that's where I'm not sure
<ElBarto>
I mean yes it's an encoder because it take RGB values and encode them to eDP
<ElBarto>
but in drm terminology I'm not sure
<libv>
drm-kms is shit anyway, says the bitter divorced father of modesetting
<ElBarto>
also if it's one, which type ? uapi/drm/drm_mode.h doesn't list any type that suits it
<ElBarto>
I don't know enough about it to have a proper argument :)
<ElBarto>
I'll just say that the doc are shit
<ElBarto>
and it's freaking hard to make a driver without looking at GPL code, which I don't want to do
<libv>
so dpmst is there, but no dp?
<libv>
not that these ids are in any way necessary
<ElBarto>
yeah I guess I can choose any ID and it won't affect things
<libv>
anyway, the tcon is half a kms crtc
sunshavi has joined #linux-sunxi
<anarsoul>
ElBarto: in linux anx6345 is bridge + connector
<libv>
in vga terms it would be the crtc, with the debe or mixer being the sequencer
<ElBarto>
anarsoul: ok, and then tcon is the encoder ? or can you have a pipeline without an encoder ?
<libv>
with randr/kms stupidity already making the connector a combination of a connector and a monitor?
<libv>
anarsoul: what infrastructure of a connector is needed for this device?
<anarsoul>
I'm not an expert in DRM, I'll look it up for you if no one else responds
<anarsoul>
libv: probing available modes?
<libv>
ElBarto: tcon also does lvds, and perhaps even mipi-dsi
<ElBarto>
libv: yes tcon0 does mipi-dsi, no idea about lvds
<libv>
so i guess they threw in rgb as a full blown encoder as well
<anarsoul>
libv: anx6345 is parallel rgb to edp bridge, the other end is edp, so you can actually read out EDID
<jernej>
mipi-dsi is separate IP block
<jernej>
but yes, it's connected to tcon0
<ElBarto>
jernej: oh really ? that's not tcon0 who does that ?
<anarsoul>
ElBarto: nope
<libv>
even though, for those who did do display drivers in the pervious decade, parallel pixel bus, clock, syncs, de, and i2c was the line between a crtc and an encoder
<ElBarto>
looks like NetBSD also set anx6345 to be a bridge+connector
AneoX has quit [Read error: Connection reset by peer]
<mru>
I get the impression that drm/kms was created as a detailed model of some specific hardware (i915?), which was fine until someone came along with hardware using a totally different partitioning of functions
<jernej>
yes, anx driver is a bridge, but that just means it can be included in display pipeline somewhere
AneoX has joined #linux-sunxi
<ElBarto>
anarsoul: another question, what's the logic with anx being endpoint 0 and dw-hdmi being endpoint 1 ?
<anarsoul>
ElBarto: no idea what you're talking about :)
<jernej>
ElBarto: can you point me DT you are looking at?
<jernej>
I did a lot of that :)
<ElBarto>
jernej: pine64-lts for dw-hdmi, anarsoul's patch for anx
<ElBarto>
binding docs talk about an allwinner,tcon-channel that is tied to the endpoint
<anarsoul>
technically it's MoeIcenowy's patch
<anarsoul>
that I was trying to upstream
<ElBarto>
but I only see this for de1
<anarsoul>
someone else is working on it now
<libv>
mru: drm/kms had a difficult birth by people who never should have been near display drivers
<libv>
and yes, a lot of development was driven by intel
<ElBarto>
jernej: no basically dw-hdmi is tied to endpoint 1 for some reason that I don't know and anx is tied to endpoint 0 for some another reason
<ElBarto>
and instead of doing if (tcon0) enpoint=0 else if (tcon1) endpoint=1 I'm trying to understand the real reason
<ElBarto>
pinebook dts with MoeIcenowy/anarsoul's patches
<ElBarto>
for dw-hdmi just look at sun50i-a64.dtsi
<ElBarto>
maybe there is something that I don't understand about ofw graph
tdebrouw has quit [Quit: Leaving.]
<libv>
the connector is pretty awful still though, if they had not insisted on keeping that as a singular object both describing a physical, passive, object (combining multiple encoders, i2c, hotplug, in the traditional dvi-i sense) and the monitor (which holds modes/ranges, a preferred mode, colour management settings, ddc/ci, all of which should actually remain when plugging to another connector), then this
<libv>
bridge thing would look different
<libv>
but making that split would mean acknowledging radeonhd even more
<jernej>
ElBarto: you mean "endpoint@0" < that 0 (in case of any6345)?
<jernej>
or "reg = <0> " ?
<ElBarto>
same thing, iirc the docs say that both are needed
<jernej>
hm, actually these two should match
<ElBarto>
yes
<jernej>
honestly I forgot why this is done in this way, let me check the code
<ElBarto>
ok, thanks
<ElBarto>
so NetBSD is creating an encoder for both tcon0 and tcon1
<ElBarto>
while I don't create an encoder for tcon1, only in the allwinner dw-hdmi driver
<ElBarto>
I don't know which one is more correct, and if there is a correct way to do that or not :)
<ElBarto>
my reason for my choice was that the pixels between tcon1 and aw-dw-hdmi was an internal format that we don't know or care about
Loewe has joined #linux-sunxi
<jernej>
ElBarto: port 1 (output) endpoint 0 is the only one that can contain panel or bridge
<jernej>
so it's meant for TCON0
<jernej>
at least according to driver
<ElBarto>
that's what I figured, but why ?
<ElBarto>
I mean why not use endpoint 0 for each tcon ?
<ElBarto>
especially since tcon1 can only output to hdmi
<ElBarto>
so why do we have an endpoint1 without an endpoint0
<ElBarto>
that really don't make sense for me
<ElBarto>
I could understand multiple endpoint for tcon0 since it can output to different thing (rgb, mipi-dsi etc ...)
<jernej>
TCON driver was writen originally for A10, A20, etc. where to my understanding same TCON block supported channel 0 and channel 1, so this decision was obviously made
<jernej>
why does it bother you so much? You can just check child node of the port
<ElBarto>
what you mean is that some bad choice were made for DE2 because of DE1 ?
<ElBarto>
it bothers me because it don't make sense :)
<ElBarto>
and I don't like to not understand why things where made like that
<ElBarto>
and each time I have such problem with DTS it's because of a technical or historical reason in Linux
<ElBarto>
and of course I don't like that :)
<jernej>
looking at TCON code now, it would probably work with hdmi endpoint 0, but at the time I wrote initial driver, it didn't
<ElBarto>
so I'll leave my if (tcon0) ... in my code and just create an encoder for tcon0
<ElBarto>
I guess I'll use DRM_MODE_ENCODER_NONE
<ElBarto>
and see if it causes problems but I doubt it
<ElBarto>
well I think that it will make more sense to use endpoint@0
<ElBarto>
but honestly I don't really care now, I just wanted to know the 'why'
<ElBarto>
thanks a lot for your answers
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
kaspter has joined #linux-sunxi
florian_kc has joined #linux-sunxi
gamelaster has quit [Read error: Connection reset by peer]
Putti has quit [Remote host closed the connection]
antoine89 has joined #linux-sunxi
<mru>
did anyone else get a private message explaining how useless we all are?
<ElBarto>
no, sorry for you :)
<antoine89>
it was me who told mru to not derail my topic anymore by askig for proof of stuff
<antoine89>
i say what i want to do, and i dont need to be questioned about why and what proof i have
<antoine89>
if you can help me, do it, if not dont
<mru>
understanding someone's reasons is necessary in order best to help them
<antoine89>
i would politely disagree
<mru>
of course you would
<antoine89>
i have found this chip that contains the BROM(boot ROM). can someone give me information if I can modify data in it or remove it? https://linux-sunxi.org/BROM
<KotCzarny>
antoine89: your questions were off-topic of this channel too
<antoine89>
sorry. which question was that?
<KotCzarny>
this channel is more about developing drivers than generic distro/app/os config
<KotCzarny>
and changing mac is generic linux question
<antoine89>
I am asking about this chip that linux-sunxi uses to provide data to the u-boot. it is not linux related
<aalm>
brom is immutable
<KotCzarny>
linux chip dont provide any mac
SopaXorzTaker has quit [Remote host closed the connection]
<KotCzarny>
erm. this chip dont provide any mac
<aalm>
and u-boot does/did come up w/mac based on SID
<KotCzarny>
aalm: depends on uboot version
<aalm>
yep, and ofc. can be overridden (env/dtb(ithink))
<antoine89>
aalm: thanks.KotCzarny: thanks . so it is possible for me to completely remvoe it? it would be easier that overwrting
<KotCzarny>
no, you cant
<antoine89>
ok. thank you very much
<KotCzarny>
and you cant overwrite it too
<antoine89>
I suspect that you are right, but I will take some time to look into it
<KotCzarny>
but, you can make it invisible from os
<KotCzarny>
by setting some access registers probably
<antoine89>
that would be interesting too
<martinayotte>
antoine89: as I said earlier, even your ISP modem as a MAC, which you can't erase this one too !
<antoine89>
martinayotte: to each his own
<martinayotte>
euuh ?
<antoine89>
yes
<martinayotte>
I don't understand your reply ...
<antoine89>
good to know
<antoine89>
my question is not realted to MAC address, but to the BROM data
<antoine89>
and I think there is not much more to add, so thanks again, and as always I will give updates
<martinayotte>
BROM is the low level bootloader of SoC, it is searching for U-Boot location and start loading it. for AllWinner SoC, it is searching first on SDCard, then eMMC, and at last form SPI_NOR.
<martinayotte>
The BROM is NOT writable !
<antoine89>
do you think that it could be replaceable?
<martinayotte>
Not at all ! BROM as nothing related with MAC !
<antoine89>
no,no. the u-boot was getting data from the BROM and creating this MAC address. it has a script for doing that
<KotCzarny>
nope
<jernej>
it's from SID
<antoine89>
if it can not find it in hte eeprom
<KotCzarny>
uboot gets data from SID
<gnarface>
i think you can build u-boot not to randomize the MAC address....
<gnarface>
i think that's a build option
<antoine89>
gnarface: thanks, I will take that into account
<gnarface>
you can also probably just specify one manually
<antoine89>
KotCzarny: i thought you meant the SID was just some register on the BROM
<martinayotte>
nope
NeuroScr has joined #linux-sunxi
<KotCzarny>
sid resides in efuse
<KotCzarny>
which is burnt in factory
<KotCzarny>
ie. you ip address and packets sent
<antoine89>
thank you very much. that is exactly what I was looking for
<antoine89>
KotCzarny: yes, but I have different use cases for such a device
<martinayotte>
Yes, futile, since anyway there is also a MAC in ISP modem ... :-P
<antoine89>
when you are behind 7 proxies that becomes less of a concern
<gnarface>
using predictable, manufacturer-assigned MAC addresses is a shortcut to getting targeted by vendor-specific 0-days though. there are still valid reasons to want to obscure your MAC. you don't have to change the hardware to do it though, you can just tell the software to ignore the value in favor of one you came up with yourself.
<gnarface>
and that is something you can do inside linux without u-boot too
<gnarface>
but i do believe that you can override this within u-boot as well