ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
surferdude has quit [Remote host closed the connection]
m5zs7k has quit [Quit: m5zs7k]
m5zs7k has joined #armlinux
apritzel has quit [Ping timeout: 252 seconds]
ajfriesen1645 has joined #armlinux
ajfriesen164 has quit [Ping timeout: 244 seconds]
ajfriesen1645 is now known as ajfriesen164
m5_ has quit [Ping timeout: 265 seconds]
m5_ has joined #armlinux
m5_ has quit [Ping timeout: 265 seconds]
heat_ has quit [Read error: Connection reset by peer]
heat_ has joined #armlinux
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #armlinux
m5_ has joined #armlinux
heat_ has quit [Ping timeout: 248 seconds]
LeSpocky has quit [Ping timeout: 248 seconds]
LeSpocky has joined #armlinux
mvaittin_ has joined #armlinux
mvaittin_ has quit [Ping timeout: 260 seconds]
mvaittin_ has joined #armlinux
mvaittin_ has quit [Ping timeout: 248 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
mvaittin_ has joined #armlinux
frieder has joined #armlinux
nsaenz has joined #armlinux
monstr has joined #armlinux
nsaenz has quit [Ping timeout: 248 seconds]
rvalue- has joined #armlinux
gclement has quit [Quit: Leaving.]
rvalue has quit [Ping timeout: 252 seconds]
rvalue- is now known as rvalue
apritzel has joined #armlinux
apritzel has quit [Ping timeout: 268 seconds]
nsaenz has joined #armlinux
nsaenz_ has joined #armlinux
nsaenz has quit [Ping timeout: 265 seconds]
luispm has joined #armlinux
cbeznea has joined #armlinux
System_Error has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
dmart has quit [Remote host closed the connection]
luispm has quit [Quit: Leaving]
Stalevar has joined #armlinux
<Stalevar>
Hello. Suppose there is a Wi-Fi router with ARM or MIPS running Linux and something. How to find out what is the address of beginning of physical memory? In particular the problem is to use uboot command to download a kernel image into RAM and then run it, and I don't want to overwrite the flash or write it into unmapped addresses
<Stalevar>
Another problem to find out the address of flash with the bootloader, so I can dump it
amitk_ has joined #armlinux
<Stalevar>
[ 0.000000] Zone ranges:
<Stalevar>
[ 0.000000] Normal [mem 0x00000000-0x07ffffff]
<Stalevar>
I got a feeling that physical ram doesn't start at 0x0 despite this line in dmesg
apritzel has quit [Ping timeout: 252 seconds]
amitk has quit [Ping timeout: 248 seconds]
rvalue has quit [Read error: Connection reset by peer]
<robmur01>
I'd usually trust that (and /proc/iomem) as an indication of what Linux has been told is RAM
rvalue has joined #armlinux
<robmur01>
Of course it may not have been RAM at cold boot time - it's not uncommon to have some range of memory-mapped boot ROM/flash initially, and a magic switch somewhere to flip that PA range to represent something else after initial boot
<Stalevar>
## Booting image at bc040000 ...
<Stalevar>
Image Name: MIPS OpenWrt Linux-3.10.14
<Stalevar>
Image Type: MIPS Linux Multi-File Image (lzma compressed)
<Stalevar>
Data Size: 1310728 Bytes = 1.3 MB
<Stalevar>
Load Address: 80000000
<Stalevar>
Entry Point: 80000000
<Stalevar>
robmur01, does it mean that bc040000 is memory-mapped flash and 80000000 is somewhere in the RAM, probably very beginning?
<robmur01>
eww, MIPS... probably the top half of PA space is a non-cacheable alias of the bottom half or something weird and MIPSy like that
<robmur01>
which would put bxxxxxxx way above that 128MB of RAM either way, likely some SRAM or XIP flash
<Stalevar>
robmur01, it's SPI flash. I don't know what is XIP
<robmur01>
eXecute In Place, i.e. memory-mapped rather than having to send explicit read commands over SPI to get data off the chip
<cambrian_invader>
physical ram starts at 0 in many processors
<cambrian_invader>
so don't rule it out right away...
fancer has joined #armlinux
<Stalevar>
So there is no way to know which address I need to write stuff I download from serial/network except reading datasheet from CPU or guessing?
System_Error has quit [Remote host closed the connection]
<Stalevar>
(again, idea was to download openwrt-kernel-initramfs image from PC and run it without overwriting original fw)
<marex>
there is likely something in the (very likely downstream, obsolete, vendor forked) U-Boot env which loads the kernel from <somewhere> to DRAM ... and if you want to update the <somewhere>, look at the U-Boot env ...
<marex>
=> printenv
<marex>
look at 'bootcmd'
<marex>
it is either SPI NOR (=> sf), or parallel nor (=> flinfo) or in case of atheros it might be directly memory mapped
siak has joined #armlinux
<headless>
Stalevar: 80000000 is likely a virtual address, the 1st 512 MiB of DRAM are mapped there (cached)
<Stalevar>
marex, the question was in general, like I wanted the fishing rod, not the fish.
<Stalevar>
but it was MT7628
<headless>
(so called KSEG0)
<headless>
the RAM is ussually mapped at 0
<headless>
*usually
<siak>
It is called fishing rod?
<Stalevar>
I mean, I wanted to know a general method to obtain memory map from a board, but it's apparently not so obvious and includes a lot of guesswork. The bootloader might be kind enough to provide it right away on UART though
<marex>
in uboot, => bdinfo
<Xogium>
marex: about being old, probably is given kernel's 3.10 LOL
<marex>
memory map is architecture specific too, and the MIPS one is a bit unusual too
<Xogium>
plus vendor can map it however they want afaik, within limitations of the architecture's memory map. Like stm32 won't have the same memory map as say, raspberry pi
<cambrian_invader>
Xogium: hey, at least it's not 2.6
<Xogium>
cambrian_invader: true, true
<Xogium>
;)
<Stalevar>
Anyway, assuming that memory starts at 80000000 what would be right address to load openwrt kernel-initramfs image into? I guess not 80000000 because kernel tries to unpack itself at this address or something
<headless>
Stalevar: surely 80000000 is a virtual address
<headless>
the physical is 0
* headless
spent couple years w/MIPS
<cambrian_invader>
it generally can't be at the very beginning because it's conventional to load the image so that the header is "negative" and the data is loaded to its final address
<cambrian_invader>
so it's common to offset by 8 MiB or whatever so you have some "headroom"
<cambrian_invader>
I think the initramfs can go anywhere though
nsaenz has quit [Remote host closed the connection]
<cambrian_invader>
of course, arch-specific stuff applies
<cambrian_invader>
e.g. on arm64 it has to be above 1G and below 32G and in the same "block" of memory as the kernel
<headless>
Stalevar: there's #mipslinux channel both on this server and OFTC
<cambrian_invader>
of course the real way is to just copy the values from the reference design...
<Stalevar>
So I got the idea. The idea is to read where kernel is loaded to and then use same address plus some offset which fits the image