Jump to content

Search the Community

Showing results for 'ar100'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Armbian
    • Armbian project administration
  • Community
    • Announcements
    • SBC News
    • Framework and userspace feature requests
    • Off-topic
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Standard support
    • Amlogic meson
    • Allwinner sunxi
    • Rockchip
    • Other families
  • Community maintained / Staging
    • TV boxes
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Support

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP/Jabber


Skype


Github


Discord


Location


Interests

  1. Starting from: https://github.com/armbian/build/commit/8278dc5e4215a84492dbe297fe243b878a60aaf4 Ref: https://github.com/crust-firmware/crust https://linux-sunxi.org/AR100
  2. I had another distro and power button nicely shut down the system and it doesn't with armbian. I have read some things about it but I'm not even sure if they apply to this board or they are updated, about acpi events, logind and AR100, and I've read the official schematics of the board. It seems the button is connected to ADC pins. I installed acpid but acpi_listen reports nothing. But evtest does! root@bananapim5:~# evtest /dev/input/by-path/platform-adc_keys-event Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "adc_keys" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 259 (BTN_3) Properties: Testing ... (interrupt to exit) Event: time 1687334663.436476, type 1 (EV_KEY), code 259 (BTN_3), value 1 Event: time 1687334663.436476, -------------- SYN_REPORT ------------ Event: time 1687334663.948482, type 1 (EV_KEY), code 259 (BTN_3), value 0 Event: time 1687334663.948482, -------------- SYN_REPORT ------------ Is there a way to tell the system that this is event is an acpi event or a driver would be needed? I don't think I can make a real driver but I think I could get read the event from /dev/input/by-path/platform-adc_keys-event with python or something. If I can't I could always wrap evtest and make it do the reading. Thanks!
  3. Description This PR adds support for Recore A5, A6, and A7 hardware. Recore is a 3D printer control board based on Allwinner A64. Since the board uses the AR100 for real time stepping, the SCP is disabled and instead a version of Klipper is loaded instead. How Has This Been Tested? The patches have been tested by building the current and legacy kernels with the minimal images. [ ] Minimal image with current kernel [ ] Minimal image with legacy kernel Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article
  4. Okay, I figured out what happens 🙂. First I would like to correct myself: the measured (idle) voltage of 1.15V was actually 1.115V. This is good. When powered down, I double-checked all regulators again and was surprised that even the SY8113 is still on, but showed a bit more than 1.3V! For some reason I must have made a mistake when measuring before as this is consistent now. Even when booting, the SY8113 shows 1.3V initially and then drops to 1.115V after a while with occasionally switching between 1.3V and 1.115V later on depending on the load. So, I did take another more detailed look at the schematics and indeed Sinovoip implemented a poor man's PMIC for the 1.1V CPUX power supply that switches between these two voltages depending on the load and the CPU clock frequency. The signal is CPUX-SET. I guess this is known as the Linux kernel seems to switch between these two voltages. Now, I'm still interested in low power consumption after poweroff. So far, the board uses more power after executing poweroff compared to running idle on Linux (~0.7-0.8W vs. ~0.5W). The reason is that all regulators keep being enabled plus the SY8113 remains to be configured for 1.3V. I'm aware of the AR100 (CPUS) and also the crust firmware on GitHub. Obviously, the hardware implements that all but one (the 3.3V) regulator can be disabled, but so far that doesn't seem to happen. How can I help here? Should I look at and modify the crust firmware, i.e. add waiting to receive a "poweroff" trigger message from the kernel and set the appropriate GPIOs accordingly? The schematic tells me that CPUS is powered by RTC_VIO (via VDD_RTC via VCC-3V3). VCC-3V3 is the only regulator which can't be turned off. So, that's in principle okay as CPUS can still monitor POWER-KEY and restart the whole system. Best, Stephan
  5. Researching background? If you want to run closed source proprietary Linux, use Xunlong / vendor stuff. If you want to use quality and open source, well, there is a looooong way. https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one but can't do many other things. Its always a trade. Providing "Armbian wallpaper" on top of Xunlong proprietary software would be dirt cheap. This particular feature is not supported yet for many reasons. You can read articles on the topic https://linux-sunxi.org/AR100 and there are many forum topics on this https://forum.armbian.com/search/?q=AR100&quick=1 Working features have nothing to do with a support status. https://docs.armbian.com/#what-is-supported We annually invest thousands of hours just into stabilising release builds vs. nothing that rolling distros do (arch - manjaro). If you need that certain feature works, pay for development to anyone you prefer. Once done, send a patch to us, we will integrate it at our cost and will maintain it if not too expensive. But you can also send it directly to kernel.org.
  6. Hi, guys. I need some help in understanding of usage AR100 (OpenRISC) coprocessor inside H3 SoC for the own real-time tasks. Now i'm using mainline kernel built with RT-PREEMPT patch. I'm using it with Machinekit (LinuxCNC) software to control stepper drivers/motors via GPIO step/dir pulses. But step pulses frequency is too slow (about 17 kHz) because the RT kernel latency is about 30 us. I think we can use the built-in coprocessor for the realtime GPIO toggling. The AR100 and main Cortex-A7 can talk to each other with built-in MSGBox. And the question is - how to launch my own firmware on the AR100 core?
  7. If things doesn't work out of the box, you have to prepare serious resources to get going. Then start here https://linux-sunxi.org/AR100/HardwareSharing This forum provide best effort support for Armbian. For other distributions, seek their support channels. If any. If none, too bad. Since you are new, welcome to read FAQ 1st. This give you some perception what you are asking for and its a way to save precious time and keep forum cleaner.
  8. It certainly works with their legacy (partially closed) stock SW / kernel interface, but for providing this function on a modern kernel, a complicated technical problem is waiting for you. Things has to be reverse engineered and port toward modern kernel base. Current status / more info here: https://linux-sunxi.org/AR100 and here.
  9. Thanks, I didn't know that. There must be a software problem/solution then. I started having a look at clocks, trying to see if setting mclk parent/rate in the dtb was having the effect I thought, there's a feature to print the clock structure: sudo cat /sys/kernel/debug/clk/clk_summary enable prepare protect duty clock count count count rate accuracy phase cycle --------------------------------------------------------------------------------------------- iosc 0 0 0 16000000 300000000 0 50000 ext_osc32k 1 1 0 32768 50000 0 50000 osc32k 1 1 0 32768 50000 0 50000 ir 0 0 0 32768 50000 0 50000 osc32k-out 0 0 0 32768 50000 0 50000 osc24M 15 15 0 24000000 50000 0 50000 ar100 1 1 0 24000000 50000 0 50000 ahb0 1 1 0 24000000 50000 0 50000 apb0 1 1 0 24000000 50000 0 50000 apb0-twd 0 0 0 24000000 50000 0 50000 apb0-i2c 0 0 0 24000000 50000 0 50000 apb0-uart 0 0 0 24000000 50000 0 50000 apb0-timer 0 0 0 24000000 50000 0 50000 apb0-ir 0 0 0 24000000 50000 0 50000 apb0-pio 1 1 0 24000000 50000 0 50000 csi-mclk 0 0 0 24000000 50000 0 50000 hdmi-ddc 2 2 0 24000000 50000 0 50000 avs 0 0 0 24000000 50000 0 50000 csi-misc 0 0 0 24000000 50000 0 50000 usb-ohci3 1 1 0 24000000 50000 0 50000 usb-ohci2 1 1 0 24000000 50000 0 50000 usb-ohci1 0 0 0 24000000 50000 0 50000 usb-ohci0 0 0 0 24000000 50000 0 50000 usb-phy3 1 1 0 24000000 50000 0 50000 usb-phy2 1 1 0 24000000 50000 0 50000 usb-phy1 0 0 0 24000000 50000 0 50000 usb-phy0 1 1 0 24000000 50000 0 50000 spi1 0 0 0 24000000 50000 0 50000 spi0 0 0 0 24000000 50000 0 50000 ce 0 0 0 24000000 50000 0 50000 ts 0 0 0 24000000 50000 0 50000 nand 0 0 0 24000000 50000 0 50000 ths 1 1 0 24000000 50000 0 50000 apb2 2 2 0 24000000 50000 0 50000 bus-scr1 0 0 0 24000000 50000 0 50000 bus-scr0 0 0 0 24000000 50000 0 50000 bus-uart3 0 0 0 24000000 50000 0 50000 bus-uart2 0 0 0 24000000 50000 0 50000 bus-uart1 0 0 0 24000000 50000 0 50000 bus-uart0 1 1 0 24000000 50000 0 50000 bus-i2c2 1 1 0 24000000 50000 0 50000 bus-i2c1 0 0 0 24000000 50000 0 50000 bus-i2c0 0 0 0 24000000 50000 0 50000 pll-de 1 1 0 432000000 50000 0 50000 de 2 2 0 432000000 50000 0 50000 wb-div 0 0 0 432000000 50000 0 50000 wb 0 0 0 432000000 50000 0 50000 mixer1-div 0 0 0 432000000 50000 0 50000 mixer1 0 0 0 432000000 50000 0 50000 mixer0-div 1 1 0 432000000 50000 0 50000 mixer0 1 1 0 432000000 50000 0 50000 tve 0 0 0 432000000 50000 0 50000 pll-periph1 0 0 0 600000000 50000 0 50000 pll-gpu 1 1 0 384000000 50000 0 50000 gpu 1 1 0 384000000 50000 0 50000 pll-periph0 6 6 0 600000000 50000 0 50000 mmc1 1 1 0 50000000 50000 0 50000 mmc2 1 1 0 50000000 50000 0 50000 mmc0 1 1 0 50000000 50000 0 50000 csi-sclk 0 0 0 300000000 50000 0 50000 deinterlace 0 0 0 600000000 50000 0 50000 ahb2 4 4 0 300000000 50000 0 50000 bus-ohci3 2 2 0 300000000 50000 0 50000 bus-ohci2 2 2 0 300000000 50000 0 50000 bus-ohci1 0 0 0 300000000 50000 0 50000 bus-ehci3 2 2 0 300000000 50000 0 50000 bus-ehci2 2 2 0 300000000 50000 0 50000 bus-ehci1 0 0 0 300000000 50000 0 50000 bus-emac 0 0 0 300000000 50000 0 50000 ahb1 11 12 0 200000000 50000 0 50000 bus-dbg 0 0 0 200000000 50000 0 50000 bus-ephy 0 0 0 200000000 50000 0 50000 bus-spinlock 0 0 0 200000000 50000 0 50000 bus-msgbox 1 1 0 200000000 50000 0 50000 bus-gpu 1 1 0 200000000 50000 0 50000 bus-de 2 2 0 200000000 50000 0 50000 bus-wb 0 0 0 200000000 50000 0 50000 bus-mixer1 0 0 0 200000000 50000 0 50000 bus-mixer0 1 1 0 200000000 50000 0 50000 bus-hdmi 2 2 0 200000000 50000 0 50000 bus-tve 0 0 0 200000000 50000 0 50000 bus-csi 0 1 0 200000000 50000 0 50000 bus-deinterlace 0 0 0 200000000 50000 0 50000 bus-tcon1 0 0 0 200000000 50000 0 50000 bus-tcon0 1 1 0 200000000 50000 0 50000 bus-ve 0 0 0 200000000 50000 0 50000 bus-ohci0 0 0 0 200000000 50000 0 50000 bus-ehci0 0 0 0 200000000 50000 0 50000 bus-otg 1 1 0 200000000 50000 0 50000 bus-spi1 0 0 0 200000000 50000 0 50000 bus-spi0 0 0 0 200000000 50000 0 50000 bus-hstimer 0 0 0 200000000 50000 0 50000 bus-ts 0 0 0 200000000 50000 0 50000 bus-dram 0 0 0 200000000 50000 0 50000 bus-nand 0 0 0 200000000 50000 0 50000 bus-mmc2 1 1 0 200000000 50000 0 50000 bus-mmc1 1 1 0 200000000 50000 0 50000 bus-mmc0 1 1 0 200000000 50000 0 50000 bus-dma 1 1 0 200000000 50000 0 50000 bus-ce 0 0 0 200000000 50000 0 50000 apb1 2 2 0 100000000 50000 0 50000 bus-i2s2 0 0 0 100000000 50000 0 50000 bus-i2s1 0 0 0 100000000 50000 0 50000 bus-i2s0 0 0 0 100000000 50000 0 50000 bus-ths 1 1 0 100000000 50000 0 50000 bus-pio 1 1 0 100000000 50000 0 50000 bus-spdif 0 0 0 100000000 50000 0 50000 bus-codec 0 0 0 100000000 50000 0 50000 pll-periph0-2x 1 1 0 1200000000 50000 0 50000 mbus 1 1 0 300000000 50000 0 50000 pll-ddr 1 1 0 1248000000 50000 0 50000 dram 1 1 0 1248000000 50000 0 50000 dram-ts 0 0 0 1248000000 50000 0 50000 dram-deinterlace 0 0 0 1248000000 50000 0 50000 dram-csi 0 0 0 1248000000 50000 0 50000 dram-ve 0 0 0 1248000000 50000 0 50000 pll-ve 0 0 0 297000000 50000 0 50000 ve 0 0 0 297000000 50000 0 50000 pll-video 2 2 0 294000000 50000 0 50000 hdmi-phy-clk 1 1 0 73500000 50000 0 50000 hdmi 1 1 0 294000000 50000 0 50000 tcon 0 0 0 294000000 50000 0 50000 pll-audio-base 0 0 0 98285714 50000 0 50000 pll-audio-8x 0 0 0 196571428 50000 0 50000 i2s2 0 0 0 196571428 50000 0 50000 i2s1 0 0 0 196571428 50000 0 50000 i2s0 0 0 0 196571428 50000 0 50000 pll-audio-4x 0 0 0 98285714 50000 0 50000 pll-audio-2x 0 0 0 49142857 50000 0 50000 pll-audio 0 0 0 98285714 50000 0 50000 ac-dig 0 0 0 98285714 50000 0 50000 spdif 0 0 0 98285714 50000 0 50000 pll-cpux 1 1 0 480000000 50000 0 50000 cpux 1 1 0 480000000 50000 0 50000 axi 0 0 0 120000000 50000 0 50000 All of our csi clocks have no statistics even after a 1080p (green/pink) capture. I know that changing the mclk rate in the dtb reached the driver because it complained once it passed the limits, but changing the clock parent doesn't reflect in this output. I don't know what to make of this though, I assume the Linux part it working well, so are we calling/reporting clock changes? Looking at the BSP code (searching "CSI_MASTER_CLK_24M_SRC" in bsp code), I think as long as the mclk rate is 6/12/24MHz the 24MHz clock is the same one they would configure. I think a clock config problem on the SoC side could be a tidy answer, it would explain why it already works for some with the same SoC. I'll keep looking in this direction for now.
  10. Sounds indeed interesting There are many people here who will help you to test, but will lack of know how to get this into their Linux. If you have a step-by-step or a .deb or something to extract at the right place. People will walk with you that way. Do you mean if you 'switch off XR819" or if you power off the device? Because the latter is known, and is not related to XR819. Keyword AR100, you find plenty in the forum and if you have some improvements there as well
  11. these guys chatting on IRC manage to somehow be really competitive in prices for the SBCs they already released. Good look to find "cheap" developers who are willing to deal with a mt6737 to get the code needed to support it upstream. linux-sunxi is somehow a curiosity... there are people which did a lot of the heavy lifting and "the party is still going" more stuff gets mainlined even for the rusty sunxi chips (e.g. encoding/decoding stuff). The only "mobile" chip from mediatek which got a bit of upstream support is the MT6797 aka X20 but even there it's not much. Not even mentioned that you then have to deal with other stuff like lk for boot of those thingies (from all the BSPs I saw, mobile mtk chips use, as most android mobile stuff, little kernel for boot). Then it comes to the, stick to the stuff you're good at. For Pinefolks, they've a proven record in designing hardware around rockchip and allwinner chips, they're familiar with the A64 with multiple boards around it so I guess they get competitive prices when sourcing parts (SoC, pmic, RAM whatever else is needed) to design 'another' board around this SoC (in fact it's just another A64 board with a special formfactor with some additional stuff like a 4g modem soldered directly). Whereas nobody expect Xunlong (from the SBC boardmaker guys) ever did a MT6737 based board. If you offer the same "as every cheap android phone" (means a smelly outdated kernel) then there's no need to call your board somehow libre IMO. For me Libre means that I'm free to load on it whatever I want to load on it. If somehow in the future pine64 is no more, or all the current OSes they try to support with this device go down the drain I can compile a kernel, glue it to whatever the next super high "mobile linux distribution" rootfs and hack around to get the 4g modem working and I still have a working device (I'll still have a upstream kernel at hand and every fancy new linux mobile distribution should be able to deal with a upstream kernel - whereas they might drop my smelly as hell BSP kernel long time ago). Cause it doesn't really matter if pine64 exists or not, the information how to deal with allwinner SoCs is spread around so that you get the missing information. As Xunlong (with the OPI 2g/4g IoT), bananapi (with various boards) and likely others too had to learn the hard way, it's hard to form a community around your SBC if the SoC used isn't already well known in the mafia (aka community ). The 2g-IoT never took off (we purged all the code supporting it, Andreas Fäber from open Suse more or less stopped his attempts to support it upstream), the 4g-IoTdidn't even made it into the buildscript (mostly cause nobody here tried to deal with little kernel for booting - it's a way harder to deal with it than with u-boot cause lack of documentation and decent examples from others how to deal with it). Even the MT7623n (BPi R2) which has a good upstream support (even with upstream u-boot support) is mostly a 1.2 man show (@frank-w managing to keep a patched upstream kernel alive counting for 1, and me counting for the other .2 dealing with getting into the buildscript here - but except a few support questions here and there, the board is mostly "dead" - I've not seen someone else working on it, except @Igor mostly as part of his usual maintainer work dealing with stuff nobody wants to deal with). Sinovoips realtek boards somehow get a bit of attention cause they're found in multiple NAS/TV boxes, kudos to @Staars @chewitt @danman et al, I know the pain of dealing with barely documented stuff - it's not that much fun for a long long time until you get something out of it. These guys try hard (!= tryhards) to glue wings to those SoCs with steady success. I guess, for a project like pine64 it would be an overkill to get familiar with a new platform ("mediatek mobile", which has currently close to no upstream support from the SoC maker upstream - their "router boards" have), funding kerneldevs to get this thing upstream and calm the community cause "nothing" works with upstream kernel in the beginnings. People tend to be nasty when things aren't working perfectly at start, except RPi folks they celebrate every new iteration no matter what works and what doesn't work properly in the beginnings. Maybe @TLLim wants to explain their decision whenever I don't see much of a reason to do so. looking a bit around on their site for maintained devices: all of them have "freedom issues" down to the bootloader. I'd prefer a proprietary display driver (in case this is really true) than a closed bootloader on a proprietary hardware (personal opinion, I've no idea how these guys define freedom, but arm chips tend to have some lowlevel CPUs in the SoC to deal with a bunch of stuff AR100 for allwinner, Videocore for broadcom - okay.. there it is 'slightly different' it controls everything except the stuff it allows you to deal with ). So if the 4g modem is directly connected to the SoC you've basically no idea what these parts of the SoC is doing all the time. And a port can still be possible even when they don't support it. The nice part about "open source" you can fork it adjust it to your hardware and there you go, a free not officially supported version of whatever piece of software you forked for your needs. The same happens to Armbian even when "we" not always like it, or Raspbian (for sure they don't like it ) and a bunch of other projects with releases their sourcecode under a common free software license - as long as you follow the license terms you're free to do whatever you want with it, even when the original writer of that piece of code doesn't like it (not sure if RPi folks like that gpiomem works on the rk3288, or their RPi cam v2.1 with a cryptographic chip on it to avoid cheaper RPi compatible imx219 cameras for the RPi also "works" on the tinkerboard - well they may like it cause they sold at least two of them more, @TonyMac32 and I had to buy one to test it - likely we would never bought one for a RPi ).
  12. The power issue is due to the USB PHY, not the radio. AR9271, which is a great chip, also has it's own CPU, running it's own closed source firmware from EEPROM, this run on a Tensilica Xtesna 2.1 microcontroller... Don't forget - the AllWinner SOC also has a hidden core for power management, and it runs it's own firmware - the AR100 - some folks have reverse engineered the blob there, but I've not seen a working example yet...
  13. It is not simple. https://forum.armbian.com/search/?q=ar100&fromCSE=1
  14. @hexdump I think axp_dummy is really just that, dummy driver. However, at some point I saw that it may call to AR100 to do voltage switching instead, but I think that's not the case here. I'm really not specialist in DVFS, so I can't answer your questions regarding that. No, I didn't do much regarding PHY driver. I just researched the topic in kernel. AFAIK we will have big pain to get it mainlined. There is no other PHY in kernel which has similar initialization sequence. We'll see. These days I was focused on implementing "half DQ" support in H6 DRAM driver for Tanix TX6 mini. Why would someone use that in media center oriented box is beyond me. It brings (much?) lower memory bandwitdh. I guess they really wanted to lower the price of the box, because they also used XR819 wifi. But yes, I received my TX6. I'm trying to add support for it to LE, but in the process I broke all other already supported boards. It has something to do with GPU, frequency and voltage regulator. In the process I also found regressions in AXP805 mainline driver (I didn't send patches yet). P.S.: These days it's very hot here, so I'm a bit slow with all this stuff. Fortunately, next days will not be so hot.
  15. From what I know, Sleep/Hibernate works only on Legacy, since it rely on AR100 ARISC co-processor, not yet supported on Mainline. That is true for all AllWinner SoC, not only H6 ... For more details, here is http://linux-sunxi.org/AR100 For example, it is well known that Pinebook with Mainline, doing sleep simply returns to normal desktop, without even doing a reboot.
  16. Support for ACPI does not exists on those boards. If you want to understand the problem https://forum.armbian.com/search/?q=ar100
  17. Who wouldn't love to have a 'proper shutdown/power management' ? Samuel Holland has enriched this page with more information https://linux-sunxi.org/AR100 . A few projects have begun to write free firmware for the AR100, using it for power management or as an independent microcontroller. Maybe you can help as well https://github.com/crust-firmware/crust/
  18. Its mainly outside our power to fix. Board makers usually doesn't add power management chips (or design doesn't allow them) which could actually power the machine off. If you have a such chip, this is simple. If you don't have it becomes complicated. If you want to understand the problem, start here: http://linux-sunxi.org/AR100 Its an example how this is solved in another cheap Allwinner H3 or H5. We have it working in H5 but not in H3 ... Single board computers have many quirks and dealing with user space problems (systemd vs initd) is out of primary focus but anyone is welcome to do changes in here - without breaking anything Oh, and someone hacked http://www.devuan.org/pwned.html
  19. As you found out by yourself, there are already topics - so I merged your comment. You need to deep dive, to understand AR100 https://linux-sunxi.org/AR100
  20. I found a new site over at sunxi, a good introduction to the topic... which might help or motivate others to test https://linux-sunxi.org/AR100/HardwareSharing and support development ?
  21. I would agree on that Le Potato from Libre Computer, is less expensive and will offer you better performance than RPi https://libre.computer/products/boards/aml-s905x-cc/#tabs_desc_684_2 Allwinner H3 is also good supported, except for the shutdown part https://linux-sunxi.org/AR100 depending on your know-how you can fix it for you or help others as well.
  22. Power down function is not supported yet on H3 boards due to lack of support for https://linux-sunxi.org/AR100 inside the kernel.
  23. By studying: http://linux-sunxi.org/AR100 https://forum.armbian.com/search/?q=AR100 and implementing.
  24. This is suspend / resume functionality. Then real power off is n/a Here http://linux-sunxi.org/AR100 you can find more info on the topic.
  25. Going back to the whole BMC issue.... Was odd that Servethehome.com brought up BMC's and the DRAC thing just before the Bloomberg article popped up... First was their BMC discussion... https://www.servethehome.com/explaining-the-baseboard-management-controller-or-bmc-in-servers/ And then the iDRAC disclosures... https://www.servethehome.com/idracula-vulnerability-impacts-millions-of-legacy-dell-emc-servers/ https://www.servethehome.com/broader-implications-of-idracula-vulnerability-a-perspective/ Were they tipped off? Timing here is interesting... SuperMicro took the hit - bloomberg.com is a financial site at the end of the day, and SuperMicro along with the two scalers (Amazon and Apple) were mentioned. A few weeks back - somebody wanted to expose HP ILO to the internet for remote management... and I strongly warned them against it. BMC"s are a raging tire fire with regards to security. so many providers do keep them on a more secured management LAN outside of production. Anyways - look at the vendor provided BSP's - only the Shadow knows what code is there... better bet is here perhaps, rather than the board/chip BSP's... This sub-thread came from discussion on the AR100 on the AllWinner H3 chip - to actually use it, one has to enable the ARM trust stuff, otherwise not...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines