lanefu changed the topic of #armbian-rockchip to: Armbian - Linux for ARM development boards | Rockchip SoC | www.armbian.com | This channel is relayed to the equivalent Discord channel | this channel is logged
_whitelogger has joined #armbian-rockchip
DC-IRC has quit [Remote host closed the connection]
<DC-IRC>
<rpardini> - How is it that you all achieve stable MAC addresses?
<DC-IRC>
<rpardini> - On a board using the SoC's ethernets (via `dwmac-rk`) it seems the rk kernel driver gets the MAC addresses from the "Rockchip Vendor Partition" config (via `rk_vendor_read(LAN_MAC_ID...)`. I've thus hacked vendor u-boot to initialise that stuff to reproducible values (based on CPU serial#) and everything works.
<DC-IRC>
<rpardini> - But how would it work on boards with PCI ethernets such as `r8125`? I can't find any `rk_vendor` stuff in that driver (thankfully, maybe). Is there further uboot-level init of PCI and settage of MAC address in uboot for those cases, or what's the magic I'm missing?
<DC-IRC>
<rpardini> Guess this is for @amazingfate @spooky8086
<DC-IRC>
<lanefu> Do the pcie nics just have real hardware MACs?
<DC-IRC>
<rpardini> Not in my boards, at least... (Mixtile) they're 00:00:00's, and get random MAC addresses with `r8125`.
<DC-IRC>
<rpardini> Vendor has a hack (for `r8169` rk driver, _not_ for `r8125`'s Realtek driver, so I had to change `CONFIG_R8125` from `=y` to `=m` otherwise `r8125` takes over first) which.... reads from Rockchip Vendor Partition.
<DC-IRC>
<rpardini> "Rockchip Vendor Partition" is a truly wondrous piece of crap. It's 3.5mb into the eMMC, or somewhere in SPI flash. There's a (Windows-only) RkDevTool-like tool that allows vendors to program it. It is immediately wiped when we flash Armbian to eMMC, of course.
<DC-IRC>
<amazingfate> We have vendor partition created in the spi flash.
<DC-IRC>
<amazingfate> If you don't flash over it, you will get a static gmac Mac address.
<DC-IRC>
<amazingfate> Every r8125 card should has its own macaddress.
<DC-IRC>
<amazingfate> Maybe there are factory tools to flash the mac address to it. But it shouldn't be the end user to do that.
<DC-IRC>
<rpardini> Yeah the ones I have (Blade3, Meko) don't have SPI flash. So it falls back to eMMC.
<DC-IRC>
<rpardini> (looks like the kernel part of a low-level tool to possibly program the r8125's MAC?)
<DC-IRC>
<amazingfate> After load driver `pgdrv` I get this `[ 1643.387056] device-mapper: ioctl: 4.44.0-ioctl (2021-02-01) initialised: dm-devel@redhat.com`
<DC-IRC>
<efectn> Does rk vendor storage have prewritten mac id value
<DC-IRC>
<efectn> Does rk vendor storage have prewritten lan mac id value
<DC-IRC>
<rpardini> Heh, in case of Meko's, apparently yes. But I can't tell, cos I flashed over it immediately and it's gone.
<DC-IRC>
<rpardini> I've used a nasty piece of Windows crap called `RKDevInfoWriteTool` that's what the vendor uses.
<DC-IRC>
<rpardini> I'm just trying to get "stable" (over multiple flashes) MAC addresses.... 🥹
<DC-IRC>
<spooky8086> I saw a commit in the opi kernel where they generate the MAC address based off the device serial number. Feels like a hack though, each ethernet port should have its own programmed MAC address.
<DC-IRC>
<amazingfate> I don't know why there are pcie ethernet card with null mac address, how are they get produced.
<DC-IRC>
<rpardini> Yeah I did similar for the uboot. It does respect any pre-flashed MAC's, and only uses serial# if it would otherwise generate a random one... it's a hack, but should be ok. Also, since we have per-board uboot's, it doesnt break anything on other boards. But for the Realtek PCI cards I'd need to hack into kernel, and that's shared so trying to find out what ya'll think.
<DC-IRC>
<rpardini> Yeah seems like Realtek has a Windows tool to program fuse or something on the r8125.
<DC-IRC>
<rpardini> Probably Radxa and others actually use it or something similar before shipping the boards....
<DC-IRC>
<spooky8086> I thought I saw a similar hack to set the MAC address in radxa's kernel history, let me check I could be wrong
<DC-IRC>
<spooky8086> Oh, the patch is for the CM3S IO, not rock 5
<DC-IRC>
<rpardini> Yeah I think Rock3 and Rock-5A uses the SoC's ethernets.... only 5B has PCIe?
<DC-IRC>
<rpardini> Assuming either Realtek or Radxa pre-fuses the MACs into the PCIe cards.... then yeah only the gmac's would need such a hack.
<DC-IRC>
<spooky8086> Yeah that sounds about right
<DC-IRC>
<rpardini> thanks for ya'lls attention 👍 I will sit on this for a while and think, not sure there's a non-terrible hack I can do...
<DC-IRC>
<Tonymac32> Nanopc T6 has space for an I2C intended to hold the MAC, it's unpopulated on mine. They use 2 PCIe adapters
<DC-IRC>
<rpardini> Hmm and you get stable MAC on the T6?
<DC-IRC>
<Tonymac32> I haven't even looked, but like I said on mine the chip isn't there 😆
<DC-IRC>
<Tonymac32> Probably something they'll do for big customers
<DC-IRC>
<rpardini> Well... sometimes the MAC is burned in to fuses/magic directly on the PCIe... like Radxa's.
<DC-IRC>
<rpardini> and the i2c would allow folks to override it?
<DC-IRC>
<rpardini> I'd love a colleague with the same problem heh 😉
<DC-IRC>
<rpardini> (not wishing any evil on you though.)
<DC-IRC>
<tenkawa42> Mystery.. anyone having uart output problems on Rock5 lately? All I've been getting with the rkr4.1 .160 tree is scrambled outpyt
<DC-IRC>
<tenkawa42> Mystery.. anyone having uart output problems on Rock5 lately? All I've been getting with the rkr4.1 .160 tree is scrambled output
<DC-IRC>
<lanefu> worked for me fine w/ rkr4.1.160 on rock5 2 weeks ago.... been working in indiedroid nova this week.. thats been working
<DC-IRC>
<tenkawa42> weird.. 1500000 8N1 right?
<DC-IRC>
<tenkawa42> What version of u-boot do you guys use?
<DC-IRC>
<tenkawa42> I want to check we are using the same
<DC-IRC>
<tenkawa42> I should probably build an updated u-boot for our build... I think its been a while
<DC-IRC>
<rpardini> BL31 sets 1500000 on rk3588's.... all the uboots I've seen follow that... and all kernels
<DC-IRC>
<tenkawa42> yaeh I thought so
<DC-IRC>
<tenkawa42> works on my rk3399 and my 115200 devices currently
<DC-IRC>
<rpardini> (I've recently been confronted with 921600 -- was flabbergasted).
<DC-IRC>
<tenkawa42> but not my 3588's
<DC-IRC>
<rpardini> just swap the UART-USB dongle.
<DC-IRC>
<tenkawa42> I have.. I have 6 of them
<DC-IRC>
<rpardini> or: use non-debug UART on another SBC?
<DC-IRC>
<rpardini> shorten jumpers, make sure you got a good GND, etc?
<DC-IRC>
<rpardini> also: the 3588's boot otherwise, right? if it's dead / maskrom there will be no output, just possible jumble on poweron/off
<DC-IRC>
<tenkawa42> I found a workaround for what I'm "really" trying to accomplish "resetting drive blocksizes"
<DC-IRC>
<tenkawa42> no.... the drives are the wrong blocksize
* DC-IRC
<rpardini> scratches head
<DC-IRC>
<tenkawa42> I was trying to figure out why
<DC-IRC>
<tenkawa42> (output)
<DC-IRC>
<rpardini> you should get BL31 output at 1500000 as long as it's there.
<DC-IRC>
<tenkawa42> Yeah
<DC-IRC>
<rpardini> no "block size" involved.
<DC-IRC>
<tenkawa42> I know why the drives have the wrong blocksize now... but being gpt you cant write these 512 byte images to a 4096 byte drive
<DC-IRC>
<tenkawa42> it scrambles it
<DC-IRC>
<rpardini> BL31 loadage is done way before any gpt is involved
<DC-IRC>
<tenkawa42> no it doesnt
<DC-IRC>
<rpardini> you mean the bootrom implements GPT partition parsing now?
<DC-IRC>
<tenkawa42> Yes
<DC-IRC>
<tenkawa42> look at the rock5 images
<DC-IRC>
<tenkawa42> spi loads them directly from gpt
<DC-IRC>
<rpardini> I think you're.... mistaken.
<DC-IRC>
<rpardini> the gpt is there, yes, but bootrom goes at specific address.
<DC-IRC>
<rpardini> either way. just flash a new uboot and be done with it
<DC-IRC>
<tenkawa42> The bootrom goes at a specific address yes... but if the table/spi is scrambled then it is going to lose its mind..
<DC-IRC>
<tenkawa42> and on a 512 byte drive it looks fine... on a 4096.. it scrambles it
<DC-IRC>
<mariob> same here, it doesn't even work in uefi because of this
<DC-IRC>
<tenkawa42> I discovered that in theory taking it back out of "Best" mode will put it back in 512 sector size and fix the problem
<DC-IRC>
<tenkawa42> this is a known issue in 3/4 of vendors drives
<DC-IRC>
<rpardini> drives?
<DC-IRC>
<tenkawa42> yes
<DC-IRC>
<rpardini> bootrom will load idbloader only from eMMC or SD or Maskrom AFAIK?
<DC-IRC>
<rpardini> bootrom will load idbloader only from eMMC or SD or Maskrom AFAIK? (and SPI)
<DC-IRC>
<tenkawa42> Western digital is one of the few that can run in Best IO mode and still run with a 512 sector size
<DC-IRC>
<tenkawa42> ie x4 pci-e
<DC-IRC>
<rpardini> that SoC won't load blobs from NVMe I think. so fix your SPI or eMMC.
<DC-IRC>
<tenkawa42> @rpardini it does it perfectly fine
<DC-IRC>
<rpardini> Oh, on the Mixtile @mariob ? Then they really skipped the "flash the realteks" step maybe.
<DC-IRC>
<mariob> bootrom only supports spi emmc and sd
<DC-IRC>
<tenkawa42> I just didn't realize that putting the sector sizes to 4096 was going to scramble it
<DC-IRC>
<tenkawa42> I'm fixing them now using another machine
<DC-IRC>
<mariob> yeah..i'm thinking of burning the efuses myself in uefi based on cpu serial
<DC-IRC>
<mariob> so that it will always persist
<DC-IRC>
<rpardini> yeah I was looking for how to do that. there's a kernel part of driver, but I couldn't find the userspace tool
<DC-IRC>
<mariob> somebody told me that friendlyelec, for instance, does not burn the MAC on consumer boards
<DC-IRC>
<tenkawa42> Wouldn't surprise me
<DC-IRC>
<rpardini> Yeah I've seen the inverse being sold as an "advantage" by some vendors. "We have _unique_ MAC addresses on our boards"
<DC-IRC>
<mariob> lol
<DC-IRC>
<lanefu> i noticed on the gl.inet routers i had.. the have 1 MAC.... and use it for ALL the interfaces
<DC-IRC>
<c0rnelius77> FE will do it if you order them in bulk or so I've read.
<DC-IRC>
<lanefu> it ends up working and mostly makign sense cuz bridging etc, but still wonky
<DC-IRC>
<rpardini> will go crazy if you plug 2 interfaces into the same (external) switch, for sure.
<DC-IRC>
<lanefu> yeah, it's just you wouldn't do that, which is why it works
<DC-IRC>
<rpardini> bonding?
<DC-IRC>
<rpardini> nah, maybe bonded will also work with same-MAC.
<DC-IRC>
<rpardini> either way same-MAC is way better than 00:00:00:00:00:00
<DC-IRC>
<lanefu> yeah... you're not gonan do any bonding with a gl.inet router 😛
<DC-IRC>
<tenkawa42> @mariob Got all of my drives switched back to 512 byte sector sizes and now they all look good.
<DC-IRC>
<tenkawa42> They may lose a "fraction" of some performance ... but in the grand scheme I'm using them for testing and on RISC-V units which can't use x4 links anyway so I wouldn't take advantage of it.