I would absolutely love it and it would be a massive help if one of you could paste this code to a new script and run it once. I don’t have any units myself that unreport RAM, but I know it’s pretty common. So getting a dump of the hardware stats will help me sort out which models do it and which RouterOS versions.
Thanks
:local pa ""; :local pb ""; :local pc ""; :local postdata "";
:set pa [:tostr [ /system routerboard get ]]; :set pb [:tostr [ /system resource get ]];
:set pc [:tostr [ /system health get ]]; :set postdata [:toarray "$pa;$pb;$pc"];
/tool fetch mode=https url="https://bl.mikrotikfilters.com/hwstats.php" http-method=post http-data="data=$postdata" output=none;
Some manufactured hAP ac2 (maybe all of them at this point?) come with 256MB of RAM instead of the stated 128. Presumably the 128MB chips were unavailable at the time of the manufacturing run so rather than hold up production, they stuck a little more on so that they could get them out the door. MT has done this kind of thing plenty of times before with RAM, flash size, CPU clock, etc.
hAP ac2 shipped with 6.40.x. The RouterOS changelog entry referenced in the first post is about a software regression that happened AFTER the hAP ac2 shipped, around (I think) 6.41, where suddenly hAP ac2 units that came with 256MB of RAM started reporting 128 instead, even though they originally reported 256 when they were first booted up with the software loaded from the factory. This was fixed, and now with current RouterOS releases, they are properly reporting 256MB again.
That’s all that this is about. It was never about RouterOS reporting MORE memory than what is available. It was about RouterOS reporting LESS memory. So if you read the spec sheet and saw 128, and you are worried that the “bug” isn’t fixed because you are seeing 256, that’s not the case. The 256 number on your board is accurate.
If you update to the latest ROS and you still see 128, then that means that you didn’t get one of the units that had 2x the RAM as what the spec sheet says it should have.
I don’t know about other threads, but in THIS thread, the two people who posted before you said:
First one, after quoting the changelog entry mentioning correct detection of RAM size: “Mine shows 233Mb RAM, is that correct in both Winbox and CLI? the specs on Mikrotik Website says it should be 128Mb” – translation: I’m running a ROS version that has the posted correction, but when I compare the RAM size to what the spec sheet shows, I have WAY more RAM than I think I should. Did the bug actually get fixed, or what?
Second one highlighted the 233MB in the copy-'n-paste, but said before that: "The same here, but no complain " – translation: hey, my router also shows >128, but I’m not going to look a gift horse in the mouth…
Clearly they were talking about the difference between the published spec sheet and what their devices are actully reporting, all in the context of a ROS changelog entry; not about 23MB missing if they assumed first that they should have 256MB, which they didn’t assume.
The changelog entry had nothing to do with the 23MB differential, and everything to do with devices that have a 256MB chip reporting ~128 instead.
It would seem that ALL hAP ac2 devices show a small chunk of “missing” RAM, regardless of RouterOS or RouterBOOT version, even if the device “thinks” it should have 128; as seen here – link to post – a device running the buggy version of the software that mis-detected 128MB only showed a “total” of 106MB. If I had to guess, there is something about the hardware architecture that demands this.
My point was that many boards do this. Example - the RB450Gx4 reports 994M instead of 1GB. The RB3011 reports 1GB. Both have the same family of IPQ ARM Processor.
Yes, the ac2 did have a bug reporting memory, I do not believe that the 233 vs 256 is representative of that bug.
That’s fine. In the meantime, I was responding to the actual question that the two people who posted before you (including the one who started this particular thread) were asking. So to say that I “missed the topic” when you were the one either hijacking the thread or misunderstanding the original post is not accurate. I wasn’t even talking to you in my original reply…
[conspiracy]Missing megabytes are not actually missing. It is hidden partition containing NSA spyware [/conspiracy]
No, seriously - it is hard to understand why would any software incorrectly detect 233MB instead of 256MB. It is not like incorrect MB/MiB conversion (that would be 244). So it is easier to assume that the changelog is not related to 233MB value. (especially as the value is displayed same way even on 6.42.6)
I just wish mikrotik did same “double size mistake” with HDD size. Having 16MB is limiting and I bet it will be not enough for ROSv7.
`
No, seriously, it actually isn’t that hard. What if it’s not a detection issue but part of upper memory has to be reserved for something else and so that part isn’t even reported by the kernel? It’s not unheard-of for certain platforms to carve out certain memory address ranges and map them to hardware I/O of some kind instead of to RAM. Whatever it is, it’s pretty clear that this is a architecture- or platform-specific issue.
I did think of improper “treating MiB as MB” but like you said, that doesn’t pencil out.
`
`
There is no guesswork/speculation/assumption required here. We know that the changelog isn’t talking about this since I literally linked to the forum post that discussed this when that changelog line was issued! The changlog is specifically talking about a bug that was introduced in early 6.42rc RouterBOOTs for the ARM platform that caused it to detect 128MB of RAM for ALL hAP ac2 boards, even the ones that actually have a 256MB chip on them!
And, again, this is not even what the original thread poster here was asking about!
Reading comprehension, people! What do they teach them in these schools!
`
`
Sometimes they do! RB450G is “only” supposed to have 512MiB of flash NAND, but I have several 450G boards that came with an entire 1GiB. RB1000 is only supposed to have 64MiB, but I have several boards (all produced around the same time / very similar serial numbers and MAC addresses) that came with 512MiB! I’m not sure if they have ever shipped more than 16MiB of flash SPI on models where they have switched to using SPI instead of NAND, but I wouldn’t bet against it sometimes happening.
part of upper memory has to be reserved for something else and so that part isn’t even reported by the kernel
wink wink conspiracy, here we go
Reading comprehension, people! What do they teach them in these schools!
Sorry for that and you are 100% right with your arguments. I just tried to answer other people before getting to your post Usually I can read and comprehend well enough.
The only way how 233MiB can be 256MB is if you have 244MiB (~256MB), but think, that you have 244MB not MiB, and do an extra conversion - down to ~233MiB
But I don’t think that’s what is happening.
To expand on the posts above, Qualcomm SoCs have a built-in hardware feature called TrustZone: https://www.arm.com/products/security-on-arm/trustzone. I suspect RouterOS does not utilize it at all. But because of the way it is implemented in the hardware, even if it is not going to utilize it, the OS still has to account for its existence.
Note the comment from the first post: “Linux doesn’t have control over these regions and they are placed in the middle of the ram before Linux even starts.” (emphasis added)
MikroTik’s own patches don’t seem to utilize DTBs, and instead their board initialization routines include one that masks out that entire region of memory:
Assuming RAM starts at 0x80000000 (a safe assumption from reading the .dtsi files referenced in the mainline kernel patches I linked to above), this reserves / carves out a 16MiB memory “hole” between 0x07000000 (112MiB) and 0x08000000 (128MiB).
This doesn’t explain the entire 23MiB, but perhaps is at least part of the solution to the mystery. And, as I speculated earlier, is due to a hardware architecture issue that there is nothing MikroTik can do anything about: the design decision was made well before it filtered down to MT engineers and is burned in silicon sourced from their upstream provider (Qualcomm).
)
Usually I can read and comprehend well enough.