<jwdonal>
crap. i figured out what i did wrong. well, at least one major thing that's wrong. probably will fix the failure to boot though
<jwdonal>
blah, sorry
<jwdonal>
SYS_SPI_U_BOOT_OFFS was not set properly
<jwdonal>
that might help a little bit
<marex>
good
<jwdonal>
yeah, that fixed the booting issue. now the reverted issue is booting. now i will try unzip on reverted version
<jwdonal>
IT WORKS!!!!!!!
<jwdonal>
unzip works on reverted version!!
<jwdonal>
Thank you so much marex!!!
<marex>
sure
<jwdonal>
so now what should i do? who should i report this issue to? what further steps should i take?
<jwdonal>
would like to help others avoid this issue
<marex>
jwdonal: dont use obsolete/broken/... downstream vendor forks , just use upstream, upstream never had this issue to begin with
<marex>
jwdonal: report it to the author of the patch, Chin Liang is I think still at intel
<marex>
jwdonal: email address is in the commit
<jwdonal>
ok got it. i will email him. "just use upstream" i would sincerely love to do that, truly, but like i said earlier i've had so many issues even getting vanilla u-boot to do anything at all on these boards that i gave up. the vendors just add so much stuff to get things working that it's hard to figure out what 1000 things i need to change to the vanilla code to make it work on these boards.
<jwdonal>
sigh. :/
<marex>
jwdonal: "the vendors just add so much stuff to get things working" ... that's not upstream fault though, complain about this to the vendors who do not upstream their board support
<marex>
btw xilinx zynq/zynqmp is pretty much fully upstream, so is the altera stuff
<jwdonal>
"that's not upstream fault though" - oh yeah totally agree with you
<jwdonal>
"so is the altera stuff" - including stratix 10 stuff?
<marex>
jwdonal: stratix and agilex both
<jwdonal>
hmm...ok, well here's what i will do. i will take the current altera version and compare the source tree contents to the current vanilla version and see how many differences there are. maybe things have gotten better since the last time i tried this
<marex>
~20kLoC, git diff --stat v2020.10..altera indicates that
<marex>
mostly DTs
<jwdonal>
don't think less of me, but what is a DT? assuming it's git lingo but i don't really use git that much
<marex>
device tree
<jwdonal>
ah
<jwdonal>
i certainly know what those are. haha. i was thinking "DTs" were some special type of git commit or something. my brain wasn't in device tree land :P
<jwdonal>
so i'm looking at the diff for these inffast.c mods that were made... but cursory glance the changes don't make much sense. "Allow machine dependent optimization for post-inc or pre-inc". ? zlib has been around for what, a few thousand years? not sure you can get much more optimization out of it at this point. haha. if it aint broke don't fix it (or in this case actually break it)
<jwdonal>
in any case, i will shoot the author an email
<jwdonal>
wonder if s/he came up with these optimizations from their own testing or if they are from somewhere else
<Tartarus>
Real quick, since we use Kconfig for ARCH, passing ARCH on the make line actively breaks things at times. And we didn't split arm64 out of arm since that didn't really make any sense
<jwdonal>
in either case, these changes have horribly broken things
<Tartarus>
it was only done in linux to make a break from existing arm support.
<Tartarus>
afk tv time
<jwdonal>
uhh...wait, so you're saying I shouldn't be specifying ARCH=arm when I build u-boot?
<Tartarus>
nope
<Tartarus>
really afk
<jwdonal>
yikes. will definitely need to stop that then
<jwdonal>
thanks!
<jwdonal>
probably goes without saying but I just confirmed that gzwrite also works flawlessly again after reverting the inffast.c changes
sakman has quit [Read error: Connection reset by peer]
sakman has joined #u-boot
vagrantc has quit [Quit: leaving]
georgem has quit [Quit: Connection closed for inactivity]
flyback has quit [Ping timeout: 268 seconds]
flyback has joined #u-boot
smartin has joined #u-boot
rfried has joined #u-boot
redbrain has joined #u-boot
smartin1 has joined #u-boot
smartin has quit [*.net *.split]
flyback has quit [*.net *.split]
smartin1 is now known as smartin
djStolen has joined #u-boot
flyback has joined #u-boot
<djStolen>
hi guys, i tried ubuntus gcc-arm-linux-gnueabi. path set at export CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-, followed by make mrproper and make mt7628_rfb_defconfigb_defconfig
<redbrain>
so you need a MIPS toolchain and not ARM based
<djStolen>
Embedded MIPS24KEc as the spec says
<djStolen>
oh, its a separate one, wasnt aware.
<djStolen>
i assumed its the same, just different switches
<djStolen>
now it makes sense
<djStolen>
u have a suggestion?
<djStolen>
which one
<redbrain>
i have no expirence in mips, but i would try gcc-mips-linux-gnu or somthing that way
<djStolen>
ok, got it. thanks
<djStolen>
awesome
<djStolen>
this is working
<djStolen>
lets see if there are some missing deps
<djStolen>
but for now runs
<djStolen>
btw, is there any how-to to check up on when porting to different board. since i am taking rfb and want to run it on xiaomi 3c
<djStolen>
?
<djStolen>
if i understood correctly, all board spec files should be here: /u-boot/board/mediatek/mt7628/
<djStolen>
are there any other files/folders that might be of interest for the board port.
<djStolen>
i guess cpu files, no need to be touched since cpu is all the same, even if the board differs.
<redbrain>
perhaps you need to adapt the devicetree files (dts)
<djStolen>
compilation successful.
<redbrain>
now the fun part begins if its booting or not :-p
<djStolen>
"perhaps you need to adapt the devicetree files (dts)", aha, i know what u mean, these i looked through yesterday evening. they looked quite thorough as the maintainer is a guy from mediatek.
<djStolen>
"now the fun part begins if its booting or not :-p" jup. just am not sure will have more time today for it :-(
<djStolen>
should i expect uart output?
<djStolen>
i mean, i would i else know it is booting
<redbrain>
if its enabled in the config files yes
<djStolen>
*how would
<djStolen>
oh, right let me se
<djStolen>
e
<djStolen>
this would say it is not?
<djStolen>
# CONFIG_DEBUG_UART is not set
<djStolen>
is it sufficient to just set it to yes or some other CONFIG is needed as well?
<redbrain>
CONFIG_DEBUG_UART is needed
<redbrain>
but perhaps you need more options for this explicit board
redbrain has quit [Ping timeout: 252 seconds]
redbrain has joined #u-boot
<djStolen>
lets see. it will be fun :-)
<djStolen>
oh, one more thing. since i bricked my board :-), i will be flashing via flashrom to flash chip directly. do u have any suggestions/tips? do i have to take care on some register addresses?
<redbrain>
do your board support some JTAG?
<redbrain>
or booting via USB-OTG
<redbrain>
you need to now the register from wich the CPU is starting on bootup
kallisti5 has joined #u-boot
<kallisti5>
how do you provide external blobs to the u-boot build?
<kallisti5>
aka to solve "Image 'main-section' is missing external blobs and is non-functional: opensbi
<djStolen>
redbrain: "do your board support some JTAG?" i am still searching for pads for JTAG, it seems it does not have, but hoping to find some way to tap to JTAG uC pads. it is a package with exposed pads, so last resort is to tap directly to uC.
<djStolen>
USB-OTG i dont know. let me see in the uC spec if it supports at all
<djStolen>
USB is there, but no word on USB-OTG.
georgem has joined #u-boot
<flyback>
wait
<flyback>
can u-boot use usb uart also for interface?
yates has quit [Quit: rcirc on GNU Emacs 25.2.2]
smartin has quit [Quit: smartin]
mmu_man has joined #u-boot
mmu_man has quit [Client Quit]
mmu_man has joined #u-boot
mmu_man is now known as mmu
mmu has quit [Quit: leaving]
mmu_man has joined #u-boot
vagrantc has joined #u-boot
<mranostaj>
flyback: explain for interface? tons of boards have a FTDI chip connected to the SoC
<flyback>
no I was talking about the fact usb 2.0 has something called ehci debug and usb 3.0 has xhci debug
<flyback>
it emulates a uart with only a memory write needed for code/driver
<flyback>
no big usb stack etc
<flyback>
it was intended to be the replacement for com ports using windows debug, linux console, etc
<flyback>
the usb 2.0 required a propritary cable some people have figured out how to emulate a nearly compatible one
<flyback>
but the xhci one is basically just a crossover cable
redbrain has quit [Ping timeout: 272 seconds]
<djStolen>
redbrain: so, got some time, so figured i follow up those JTAG lines on the board. it seems as not so easy job after all since the board is painted in black. out of 5 JTAG pins, 3 are having directly visible lines. JTAG_RST, JTAG_MS, JTAG_DO. Now funny thing with this uC is that these pins are also named LED(something) as if they are predetermined
<djStolen>
for usage with LED, and truly, the lines are leading to 3 unpopulated LED slots. In vicinity of each unpopulated LED slot there are 2 resistors and 1 capacitor populated. Now what makes me wonder are those resistors and capacitor on JTAG lines. Either:
<djStolen>
A) 2 resistors and 1 cap are there for LED which is not populated? Why would they be there as well if LED is not populated?
<djStolen>
its D) those 3 lines are driving the LEDs integrated into the ethernet sockets. :-) Thats why LED circuitry is populated even though LEDs are missing on the board.
<djStolen>
ok 3 JTAG pads available as unpopulated LED pads can be misused. Question is, that RC filter (it's 1 R and 1 C, the other R is on the communication line, just in vicinity) could filter out JTAG comm. Possibly it must go away.
<djStolen>
big quest though, for another day, is those 2 missing JTAG lines, as they seem to be only on the uC pins at the moment