<bih420[m]>
<marex> "sure" <- I have to buy some items, in a few weeks hope I have good result to show thanks for helping me and clearing my doubts
<bih420[m]>
if you u-boot on matrix that will quite easy for me because I don't want to relays to connect irc :(
<marex>
bih420[m]: maybe the item you can buy instead is this turris omnia, it is supported by upstream u-boot, the hardware is OK
<bih420[m]>
marex: wow nice product imo, but it will not ship in my country
<marex>
oh hum
<marex>
maybe solidrun clearfog might
<vagrantc>
clear as fog?
<marex>
soc is similar , upstream support not so much
<bih420[m]>
i got it all are marvel chips
<bih420[m]>
but can i get in bcom or qcom
<bih420[m]>
because porting u-boot is only first stage of my target and there are 3 more stages
<bih420[m]>
thats why linksys router use marvell chip i understand and they have u-boot
<marex>
bih420[m]: oh, well ... if your goal is to do u-boot porting for the sake of u-boot porting ...
<marex>
bih420[m]: it might make sense to grab some more documented SoC/board
<bih420[m]>
and learn in those nice idea i have spare pi3 in my hand right now
<marex>
might make sense to pick some simpler/older hardware and build up the skill set
<marex>
having documentation isntead of having to reverse-engineer stuff is always a huge benefit
vagrantc has quit [Quit: leaving]
<bih420[m]>
<marex> "having documentation isntead..." <- the problem is i didn't understand Broadcomm cpu thing a letter change and u-boot on other router supported
<bih420[m]>
I have to research more about why high end router have marvel
<marex>
well, high end routers have FPGAs and ASICs really
<marex>
the high end consumer hardware is usually an arm64 soc + some sort of programmable switch
<marex>
(or arm32 soc, or mips, ...)
<bih420[m]>
marex: 64 wow, i am still on 32 bit router thinking of tinker this so i will learn than migrate to 64
<bih420[m]>
recently learn about edk2 and understand UEFI concept
<bih420[m]>
s/learn/learned/
<bih420[m]>
even if I buy high end broadcom router they used CFE but in the case of marvel it is u-boot. I have other questions but don't want to ask here as it was partially related u-boot and mainly reverse engineering.
<marex>
you can ask, if someone knows the answer and has time, they might answer ...
<bih420[m]>
cyrozap: thanks and openwrt said bcm5xxx something but still question is how to compile for that like there is conf for bcm7xxx but not for bcm4xxx or bcm5xxx. i have to complete my homework first
<marex>
bih420[m]: find chip datasheet, read it, it is quite likely the other bcm chips use the same or similar IPs
<marex>
its not like the vendors just up and reinvent everything in every chip
<marex>
they usually recycle and/or slightly modify IPs, or outright buy them from 3rd parties
<bih420[m]>
you are right so bcm ip is locked or proprietary hmm doing reverse engineering without documentation :pain
<marex>
it means you could even find documentation for some of the IPs in other related datasheets
<bih420[m]>
thank you so much. you guys are the best
<cyrozap>
Since this hardware is already supported in mainline Linux, porting U-Boot ("proper", i.e., just the code that loads Linux, not memory training or other very early initialization) should be straightforward, since you can use the Linux drivers as a reference when writing the ones for U-Boot.
<marex>
its the dram and all that init which would be difficult
<bih420[m]>
cyrozap: understood, i have to take time to digest this after that analysis hope in the end i found positive result thank you so much
<bih420[m]>
<marex> "its the dram and all that init..." <- let me reach to that stage. too early to comment anything
<cyrozap>
bih420[m]: Yeah, reverse engineering the DRAM and other early init would involve tracing what the proprietary boot code does. Which isn't entirely infeasible--I'm actually doing something similar with some MediaTek SoCs--but could be very challenging for you don't have much experience with this kind of reverse engineering. For now, I'd start at a higher level and then work my way down. So, first get Linux
<cyrozap>
to boot using the proprietary bootloader, so you have some "known working" kernel code/configuration. Then, try replacing the part of the bootloader that loads Linux (the bootloader is generally in two stages--the part that runs in SRAM and initializes power, clocks, DRAM, etc., and the part that runs in DRAM and boots Linux) with U-Boot. Then, when you have that part of U-Boot working, you can try
<cyrozap>
reverse engineering that first stage of the bootloader (power, clocks, and DRAM init), document what it does, and then write the U-Boot SPL code based on that documentation.
<marex>
... and attach JTAG or other manner of recovery
<bih420[m]>
marex: sure 😉 ordered jlink now need some helping hands lol
tomekb has quit [Remote host closed the connection]
<bih420[m]>
thanks @cyrozap i will make a plan hope i give something positive result if not still i learned something but thank you so much guys you helped a newbie to clear his doubt
<bih420[m]>
thanks @cyrozap i will make a plan hope i give something positive result if not still i learned something but thank you so much guys you helped a newbie to clear his doubt
<cyrozap>
Or you can use my preferred method, which is to desolder the flash chip, solder a socket (e.g., https://www.dediprog.com/category/smt-sockets, which admittedly are rather expensive, but I've had a hard time finding them cheaper elsewhere) in its place, and reprogram the flash with an external programmer.
<bih420[m]>
Or you can use my preferred method, which is to desolder the flash chip, solder a socket (e.g., https://www.dediprog.com/category/smt-sockets, which admittedly are rather expensive, but I've had a hard time finding them cheaper elsewhere) in its place, and reprogram the flash with an external programmer.
<marex>
cyrozap: which fails when you start to debug code btw ;-)
<marex>
but yes, resocketing the spi nor has its uses
<cyrozap>
I like the "socketed flash" method since it means I can completely disconnect the flash from the system during programming, and makes it easy to swap chips if I'm testing differences between a "known good" and "test" version of some code without having to reprogram the flash a bunch of times, and it always works, even on systems that don't have JTAG or whose JTAG function is disabled.
<cyrozap>
But yes, it's also good to have JTAG for debugging things that can't be debugged with printf().
macromorgan has quit [Read error: Connection reset by peer]
macromorgan_ has joined #u-boot
macromorgan_ is now known as macromorgan
<marex>
cyrozap: but you have to make physical effort and manipulate with electronics :)
<marex>
also it doesnt have gdb support
<bih420[m]>
/offtopic my country banned aliexpress :(
<cyrozap>
bih420[m]: In that case, you might be able to find those things on similar sites locally. I'm not sure what the equivalent of eBay and Amazon are where you are, but you might be able to find that stuff there, too.
<bih420[m]>
<cyrozap> "bih420: To add to what marex..." <- is that for uart ft232H, i can have CH341A by tomorrow. i have PL2303HX
<cyrozap>
No, the FT232H is for SPI (though it can also do UART). The CH341A is just for SPI.
<bih420[m]>
i have amazon here ch341a + PL2303HX can float my boat i guess
<bih420[m]>
PL2303HX is thing which i use for uart
<bih420[m]>
ok i will order 2 if i screwed up on one i can’t get cone soldering :(
<cyrozap>
bih420[m]: Sorry, I didn't mean you might fry the CH341A board--I meant you might fry your router's SoC or flash. Those CH341A programmers put out 5V on their I/O pins, so if your flash or router SoC aren't 5V-tolerant, it could make the pins stop working.
<cyrozap>
The pins on the SoC or flash, I mean.
<bih420[m]>
just curious if i was able to 3.3v than i don’t have fry anything on my router? above blog doing for thinkpad
<bih420[m]>
i have a backup plan if i done anything wrong i will replace this router :p
<cyrozap>
bih420[m]: Your router most likely has 3.3V-only I/O pins. At least, I haven't seen one in the past 15 years that used 5V I/O. And it's not guaranteed that it'll break your router--there's just a good chance that it'll get damaged over time and eventually stop working.
<cyrozap>
So, you can try without making the modification, and it may work, but you might want to use the JTAG method instead if you can.
<bih420[m]>
cyrozap: ok i learned something today :) yeap i am looking forward for Jtag as main focus other i ordered just for future if covid came again :(
<j`ey>
u-boot doesnt support .cpio.tar.gz initrds?
<j`ey>
trying to create a FIT image like so: ./tools/mkimage -i ../busybox/rootfs.cpio.gz fit-rootfs, gives me "Can't open (null): Bad address"
<j`ey>
I managed to create one with ./tools/mkimage -A arm64 -T ramdisk -C gzip -d ../busybox/rootfs.cpio.gz urootfs.cpio.gz, but that seems to be using the legacy format
<Forty-Bot>
U-Boot doesn't care what the initrd format is